High Efficiency Streaming Protocol: Difference between revisions

Content deleted Content added
Declining submission: nn - Submission is about a topic not yet shown to meet general notability guidelines (be more specific if possible) and context - Submission provides insufficient context (AFCH 0.9.1)
JonSul21 (talk | contribs)
Hi Modussiccandi, many thanks for your feedback. I've reworded some sections to make them more accessible for the broader public. Extra references have also been added. Hope this addresses your feedback - please let me know if you feel other updates should be made before the article can be published, and I'd then be happy to look into these!
Line 6:
 
== High Efficiency Streaming Protocol (HESP) ==
'''High Efficiency Streaming Protocol''' (also known as '''HESP''') is an [[Hypertext Transfer Protocol|HTTP]]-based [[adaptive bitrate streaming]] techniqueprotocol that enables high-quality [[Streaming media|streaming]] of media content over the Internet delivered from conventional [[Hypertext Transfer Protocol|HTTP]] web servers.<ref>{{Cite web |title=What is the High Efficiency Streaming Protocol (HESP) Allianceand why does the video industry need it? |url=https://www.hespalliancetheoplayer.orgcom/blog/what-is-the-high-efficiency-streaming-protocol-hesp-and-why-does-the-video-industry-need-it |access-date=2023-02-07-04 |website=HESP AllianceTHEO Technologies|language=en-US}}</ref>, just like [[HTTP Live Streaming|HLS]] and [[Dynamic Adaptive Streaming over HTTP|DASH]]. The technology was developed by THEO Technologies and made available via the HESP Alliance, which has [[Synamedia]] and THEO Technologies as founding members.<ref>{{Cite web |title=[PRESS RELEASE] THEO Technologies and Synamedia form HESP Alliance |url=https://www.theoplayerdigitaltvnews.com/blognet/hesp-alliance-announced?p=34815 |access-date=2023-02-07-04 |website=Digital TV News |language=en-us}}</ref> HESP brings sub-second [[Latency (engineering)|latency]] and a fast channel change, and is seen as a challenger of Low Latency [[HTTP Live Streaming|HLS]] (LL-HLS, first released in 2009) and Low Latency [[Dynamic Adaptive Streaming over HTTP|DASH]] (LL-DASH, standardized in 2012).<ref>{{Cite web |title=Rethink report debunks low latency hype |url=https://www.theoplayercsimagazine.com/csi/Rethink-report-debunks-low-latency-hype.php |access-date=2023-07-04 |website=CSI Magazine |language=en-us}}</ref>.
 
== Architecture ==
HTTP-based streaming protocols such as HLS and DASH typically use a segment-based approach. This means a video is cut up into [[Transmission Control Protocol|TCP]] segments of a few seconds each, which requires video players to wait until the start of a new segment to start playback. This approach increases channel change times and introduces additional latency. HESP leverages a frame-based streaming approach, which does not require a trade-off between live latency and channel switching time.<ref>{{Cite web |title=HESP: Sub-second Latency, Fast Channel Change and Improved ABR over Standard CDNs |url=https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=153579 |access-date=2023-07-04 |website=Streaming Media |language=en-us}}</ref>
HESP leverages two complementary streams: an initialization stream and a continuation stream. The initialization stream is a stream with all [[Key frame|keyframes]]. This stream is only used at startup. At that moment, the most recent image available in the initialization stream is requested<ref>{{Cite news |title=HESP - High Efficiency Streaming Protocol |language=en |work=IETF Datatracker |url=https://datatracker.ietf.org/doc/draft-theo-hesp/ |access-date=2023-02-07}}</ref>. As the initialization stream’s images are all keyframes, playback can start immediately, resulting in very fast channel start and switch times. Subsequently, through a [[Byte serving|range request]], images are requested from the continuation stream<ref>{{Cite news |title=HESP - High Efficiency Streaming Protocol |language=en |work=IETF Datatracker |url=https://datatracker.ietf.org/doc/draft-theo-hesp/ |access-date=2023-02-07}}</ref>, a regularly encoded stream for low [[Latency (engineering)|latency]] purposes. HESP is delivered over HTTP/1.1. It uses [[Chunked transfer encoding|Chunked Transfer Encoding]] (CTE) at a very granular level, i.e. each chunk is a frame, to allow for ultra-low latency delivery. HESP requires implementation in the packager and player, and support for range requests and CTE in the [[Content delivery network|CDN]].
 
When all components of the video workflow are optimized for low latency, HESP can provide for sub-second latency.<ref>{{Cite web |title=HESP: What a HESP protocol is and how it changes streaming for the better |url=https://gcore.com/learning/what-a-hesp-protocol-is-and-how-it-changes-streaming-for-the-better/ |access-date=2023-07-04 |website=Gcore |language=en-us}}</ref>
 
HESP requires implementation in the packager and player, and support for [[byte serving|range requests]] and [[Chunked transfer encoding]] (CTE) in the [[Content delivery network|CDN]].<ref>{{Cite web |title=HESP - Informational Draft |url=https://datatracker.ietf.org/doc/draft-theo-hesp/ |access-date=2023-07-04 |website=IETF |language=en-us}}</ref>
 
== Standardization ==
Work on HESP started in 2018; it became an IETF information draft in May 2021<ref>{{Cite web |title=High Efficiency Streaming Protocol (HESP) |url=https://theiabm.org/bamproducts/high-efficiency-streaming-protocol-hesp/ |access-date=2023-02-07-04 |website=IABM |language=en-US}}</ref>.
 
The HESP Alliance, launched in 2020, promotes and catalyzes the adoption of HESP. It consists of streaming vendors and media companies, including [[Synamedia]], THEO Technologies, G-Core, EZDRM, Mainstreaming, NativeWaves and Hoki. The HESP Alliance technical working group is focused on further advancing the HESP standard<ref>{{Cite web |title=HESP Alliance Members |url=https://www.hespalliance.org/members |access-date=2023-02-07-04 |website=HESP Alliance |language=en-US}}</ref>
 
== References ==