Editing Streaming media (section)

==Technologies==
=== Bandwidth ===
A broadband speed of 2&nbsp;Mbit/s or more is recommended for streaming [[standard-definition video]],<ref>{{cite web | url=https://www.broadbandchoices.co.uk/guides/internet/watching-tv-online | title=How to watch live TV online: The complete guide | work=broadbandchoices | date=20 May 2016 | access-date=1 October 2016 | author=Staples, Kim | archive-date=16 May 2016 | archive-url=https://web.archive.org/web/20160516142628/http://www.broadbandchoices.co.uk/guides/internet/watching-tv-online | url-status=live }}</ref> for example to a [[Roku]], [[Apple&nbsp;TV]], [[Google TV (operating system)|Google&nbsp;TV]] or a Sony&nbsp;TV Blu-ray Disc Player. 5&nbsp;Mbit/s is recommended for high-definition content and 9&nbsp;Mbit/s for [[Ultra-high-definition television|ultra-high-definition content]].<ref>Minimum requirements for Sony&nbsp;TV Blu-ray&nbsp;Disc Player, on advertisement attached to a NetFlix&nbsp;DVD{{Nonspecific|date=March 2011}}</ref> Streaming media storage size is calculated from the streaming bandwidth and length of the media using the following formula (for a single user and file): storage size in [[megabyte]]s is equal to length (in seconds) × [[bit rate]] (in bit/s) / (8 × 1024 × 1024). For example, one hour of digital video encoded at 300&nbsp;kbit/s (this was a typical broadband video in 2005 and it was usually encoded in {{resx|320 × 240}} resolution) will be: (3,600&nbsp;s&nbsp;× 300,000&nbsp;bit/s)&nbsp;/ (8&nbsp;× 1024&nbsp;× 1024) requires around 128&nbsp;[[Megabyte|MB]] of storage.

If the file is stored on a server for on-demand streaming and this stream is viewed by 1,000 people at the same time using a [[Unicast]] protocol, the requirement is 300&nbsp;kbit/s&nbsp;× 1,000&nbsp;= 300,000&nbsp;kbit/s&nbsp;= 300&nbsp;Mbit/s of bandwidth. This is equivalent to around 135&nbsp;[[gigabyte|GB]] per hour. Using a [[multicast]] protocol the server sends out only a single stream that is common to all users. Therefore, such a stream would only use 300&nbsp;kbit/s of server bandwidth.

In 2018 video was more than 60% of data traffic worldwide and accounted for 80% of growth in data usage.<ref>{{Cite web|title=The myth of the green cloud|url=https://www.eib.org/en/stories/digital-footprint |first1=Shirley |last1=Rizk |date=21 June 2019 |access-date=17 September 2020|website=European Investment Bank|language=en|archive-date=14 April 2021|archive-url=https://web.archive.org/web/20210414035732/https://www.eib.org/en/stories/digital-footprint|url-status=live}}</ref><ref>{{Cite web|title= Cisco Annual Internet Report (2018–2023) White Paper|url=https://www.cisco.com/c/en/us/solutions/collateral/executive-perspectives/annual-internet-report/white-paper-c11-741490.html|access-date=17 September 2020|website=Cisco|language=en|archive-date=7 February 2014|archive-url=https://web.archive.org/web/20140207074720/http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-520862.html|url-status=live}}</ref>

=== Protocols ===
[[File:Unicast streaming.svg|thumb|Unicast connections require multiple connections from the same streaming server even when it streams the same content.]]

Video and audio streams are compressed to make the file size smaller. [[Audio coding format]]s include [[MP3]], [[Vorbis]], [[Advanced Audio Coding|AAC]] and [[Opus (audio format)|Opus]]. [[Video coding format]]s include [[H.264]], [[HEVC]], [[VP8]] and [[VP9]]. Encoded audio and video streams are assembled in a container [[bitstream]] such as [[MPEG-4|MP4]], [[FLV]], [[WebM]], [[Advanced Systems Format|ASF]] or [[Internet Streaming Media Alliance|ISMA]]. The bitstream is delivered from a streaming server to a streaming client (e.g., the computer user with their Internet-connected laptop) using a transport protocol, such as Adobe's [[Real-Time Messaging Protocol|RTMP]] or [[Real-time Transport Protocol|RTP]].

In the 2010s, technologies such as Apple's [[HTTP Live Streaming|HLS]], Microsoft's Smooth Streaming, Adobe's HDS and non-proprietary formats such as [[MPEG-DASH]] emerged to enable [[adaptive bitrate streaming]] over [[HTTP]] as an alternative to using proprietary transport protocols. Often, a streaming transport protocol is used to send video from an event venue to a [[Cloud computing|cloud]] transcoding service and [[content delivery network]], which then uses HTTP-based transport protocols to distribute the video to individual homes and users.<ref>{{cite web|title = Streaming the London Olympic Games with the 'Go Live Package' from iStreamPlanet and Haivision |url = http://www.istreamplanet.com/casestudy/the-london-olympic-games-go-live-package/|website = iStreamPlanet |access-date = 11 November 2015|archive-url = https://web.archive.org/web/20160101140531/http://www.istreamplanet.com/casestudy/the-london-olympic-games-go-live-package/|archive-date = 1 January 2016|url-status = dead}}</ref> The streaming client (the end user) may interact with the streaming server using a control protocol, such as [[Microsoft Media Server|MMS]] or [[RTSP]].

The quality of the interaction between servers and users is based on the workload of the streaming service; as more users attempt to access a service the quality may be affected by resource constraints in the service.<ref>{{Cite book|last1=Sripanidkulchai|first1=Kunwadee|last2=Maggs|first2=Bruce|last3=Zhang|first3=Hui|title=Proceedings of the 4th ACM SIGCOMM conference on Internet measurement |chapter=An analysis of live streaming workloads on the internet |year=2004|series=IMC '04|location=New York, NY, US|publisher=ACM|pages=41–54|doi=10.1145/1028788.1028795|isbn=9781581138214|s2cid=1742312}}</ref> Deploying clusters of streaming servers is one such method where there are regional servers spread across the network, managed by a singular, central server containing copies of all the media files as well as the [[IP address]]es of the regional servers. This central server then uses [[Load balancing (computing)|load balancing]] and [[Scheduling (computing)|scheduling]] algorithms to redirect users to nearby regional servers capable of accommodating them. This approach also allows the central server to provide streaming data to both users as well as regional servers using [[FFmpeg]] libraries if required, thus demanding the central server to have powerful data processing and immense storage capabilities. In return, workloads on the streaming backbone network are balanced and alleviated, allowing for optimal streaming quality.<ref>{{cite journal |last1=Zhao |first1=Hong |last2=Chun-long |first2=Zhou |last3=Bao-zhao |first3=Jin |title=Design and Implementation of Streaming Media Server Cluster Based on FFMpeg |journal=The Scientific World Journal |date=3 February 2015 |volume=2015 |pages=963083 |doi=10.1155/2015/963083 |pmid=25734187 |pmc=4334929 |doi-access=free }}</ref>{{update inline|reason=2017 academic source. This is now normally accomplished automatically in CDNs.|date=April 2023}}

Designing a network protocol to support streaming media raises many problems. [[Datagram]] protocols, such as the [[User Datagram Protocol]] (UDP), send the media stream as a series of small packets. This is simple and efficient; however, there is no mechanism within the protocol to guarantee delivery. It is up to the receiving application to detect loss or corruption and recover data using [[error correction]] techniques. If data is lost, the stream may suffer a [[Dropout (communications)|dropout]]. The [[Real-Time Streaming Protocol]] (RTSP), [[Real-time Transport Protocol]] (RTP) and the [[Real-time Transport Control Protocol]] (RTCP) were specifically designed to stream media over networks. RTSP runs over a variety of transport protocols,<ref>{{Cite web |date=2021-07-08 |title=RTSP: The Real-Time Streaming Protocol. What is RTSP and How Does It Work? |url=https://antmedia.io/rtsp-explained-what-is-rtsp-how-it-works/ |access-date=2025-01-06 |website=antmedia.io |language=en-US}}</ref> while the latter two are built on top of UDP.

HTTP adaptive bitrate streaming is based on HTTP progressive download, but contrary to the previous approach, here the files are very small, so that they can be compared to the streaming of packets, much like the case of using RTSP and RTP.<ref>Ch. Z. Patrikakis, N. Papaoulakis, Ch. Stefanoudaki, M. S. Nunes, "Streaming content wars: Download and play strikes back" presented at the Personalization in Media Delivery Platforms Workshop, [218 – 226], Venice, Italy, 2009.</ref> Reliable protocols, such as the [[Transmission Control Protocol]] (TCP), guarantee correct delivery of each bit in the media stream. It means, however, that when there is data loss on the network, the media stream stalls while the protocol handlers detect the loss and retransmit the missing data. Clients can minimize this effect by buffering data for display. While delay due to buffering is acceptable in video-on-demand scenarios, users of interactive applications such as video conferencing will experience a loss of fidelity if the delay caused by buffering exceeds 200&nbsp;ms.<ref>Krasic, C. and Li, K. and Walpole, J., ''The case for streaming multimedia with TCP'', Lecture Notes in Computer Science, pages 213–218, Springer, 2001</ref>

[[File:Multicast stream.svg|thumb|Multicasting broadcasts the same copy of the multimedia over the entire network to a group of clients]]

[[Unicast]] protocols send a separate copy of the media stream from the server to each recipient. Unicast is the norm for most Internet connections but does not scale well when many users want to view the same television program concurrently. [[Multicast]] protocols were developed to reduce server and network loads resulting from duplicate data streams that occur when many recipients receive unicast content streams independently. These protocols send a single stream from the source to a group of recipients. Depending on the network infrastructure and type, multicast transmission may or may not be feasible. One potential disadvantage of multicasting is the loss of [[video on demand]] functionality. Continuous streaming of radio or television material usually precludes the recipient's ability to control playback. However, this problem can be mitigated by elements such as caching servers, digital [[set-top box]]es, and buffered [[Media player (application software)|media players]].

[[IP multicast]] provides a means to send a single media stream to a group of recipients on a [[computer network]]. A connection management protocol, usually [[Internet Group Management Protocol]], is used to manage the delivery of multicast streams to the groups of recipients on a LAN. One of the challenges in deploying IP multicast is that routers and firewalls between LANs must allow the passage of packets destined to multicast groups. If the organization that is serving the content has control over the network between server and recipients (i.e.,&nbsp;educational, government, and corporate [[intranet]]s), then routing protocols such as [[Protocol Independent Multicast]] can be used to deliver stream content to multiple [[local area network]] segments.

[[Peer-to-peer]] (P2P) protocols arrange for prerecorded streams to be sent between computers. This prevents the server and its network connections from becoming a bottleneck. However, it raises technical, performance, security, quality, and business issues.

[[Content delivery network]]s (CDNs) use intermediate servers to distribute the load. Internet-compatible unicast delivery is used between CDN nodes and streaming destinations.

=== Recording ===
Media that is livestreamed can be recorded through certain media players, such as [[VLC player]], or through the use of a [[screen recorder]]. Live-streaming platforms such as [[Twitch (service)|Twitch]] may also incorporate a [[video on demand]] system that allows automatic recording of live broadcasts so that they can be watched later.<ref>{{cite web|url=https://help.twitch.tv/customer/portal/articles/1575302-videos-on-demand|title=Videos On Demand|access-date=8 May 2017|archive-date=15 December 2018|archive-url=https://web.archive.org/web/20181215225249/https://help.twitch.tv/customer/portal/articles/1575302-videos-on-demand|url-status=dead}}</ref> YouTube also has recordings of live broadcasts, including television shows aired on major networks. These streams have the potential to be recorded by anyone who has access to them, whether legally or otherwise.<ref>{{Cite journal|last1=Burroughs|first1=Benjamin|last2=Rugg|first2=Adam|date=3 July 2014|title=Extending the Broadcast: Streaming Culture and the Problems of Digital Geographies|journal=Journal of Broadcasting & Electronic Media|volume=58|issue=3|pages=365–380|doi=10.1080/08838151.2014.935854|s2cid=144577408|issn=0883-8151}}</ref>

Recordings can happen through any device that allows people to watch movies they do not have access to or be at a music festival they could not get tickets to. These live streaming platforms have revolutionized entertainment, creating new ways for people to interact with content. Many celebrities started live streaming during COVID-19 through platforms like [[Instagram]], [[YouTube]], and [[TikTok]] offering an alternate form of entertainment when concerts were postponed. Live streaming and recording allow for fans to communicate with these artists through chats and likes.

=== View recommendation ===
Most streaming services feature a [[recommender system]] for viewing based on each user's view history in conjunction with all viewers' aggregated view histories. Rather than focusing on subjective categorization of content by content curators, there is an assumption that, with the immensity of data collected on viewing habits, the choices of those who are first to view content can be algorithmically extrapolated to the totality of the user base, with increasing probabilistic accuracy as to the likelihood of their choosing and enjoying the recommended content as more data is collected.<ref>{{Cite book |last=Buijsman |first=Stefan |title=Pluses and Minuses: How Math Solves Our Problems |url=https://books.google.com/books?id=TYzzDwAAQBAJ&pg=PA13 |publisher=Penguin Books |year=2018 |isbn=978-0-14-313458-9 |edition=English |location=Amsterdam |pages=12–16 |language=Dutch}}</ref>