DOCSLIB.ORG

The Internet Needs a Competitive, Royalty-Free Video Codec James Bankoski, Matthew Frost and Adrian Grange

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Internet Needs a Competitive, Royalty-Free Video Codec James Bankoski, Matthew Frost and Adrian Grange SIP (2017),vol.6,e13,page1of7©TheAuthors,2017. This is an Open Access article, distributed under the terms of the Creative Commons Attribution licence (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted re-use, distribution, and reproduction in any medium, provided the original work is properly cited. doi:10.1017/ATSIP.2017.14 industrial technology advances The internet needs a competitive, royalty-free video codec james bankoski, matthew frost and adrian grange In this paper, we present the argument in favor of an open source, a royalty-free video codec that will keep pace with the evolution of video traffic. Additionally, we argue that the availability of a state-of-the-art, royalty-free codec levels the playing field, allowing small content owners, and application developerso t compete with the larger companies that operate in this space. Keywords: Royalty free, MPEG, Alliance for Open Media, Video compression Received 15 August 2017; Revised 2 November 2017; Accepted 2 November 2017 I. INTRODUCTION II. BACKGROUND Given the central role that the internet plays in modern life, Thefirstdigitalvideocodecstandards,H.120(1984)and internet bandwidth should be considered a scarce resource, H.261(1988),weredevelopedattheInternationalTelecom- demanding careful consideration as to how we consume it munication Union (ITU) and primarily intended for video- to maximize its utility. phone and video-conferencing use-cases. Both standards Global internet traffic is predicted to increase nearly were royalty-free. It was not until the 1995 development of threefold between 2016 and 2021, and the proportion of MPEG-2/H.262 that standards defined video codecs were video traffic is expected to rise from 73 to 82 over the monetized when the US Department of Justice approved same period [1], driven in part by the move of content from MPEG-LA [2], a company unaffiliated with either MPEG broadcast to online delivery channels and to the rapid evo- orISO,toformapatentpoolwiththeaimofcollecting lution of virtual reality applications. There is considerable royalties from the patents considered “essential” for imple- concern that the growth rate of intellectual property (IP) mentation. Royalties were set at $6 per unit for devices that trafficwillexceedtherateatwhichnetworkcapacityisbeing could both encode and decode, and $4 per unit for a device expanded. capable only of decoding. Adding network capacity means increasing network This pricing was seen as a problem in early 2001 when speed, particularly the last mile where the traffic leaves the the research work around AVC/H.264 was begun by the high-speed trunk networks as it is delivered to individual Joint Video Team (JVT), a group of video coding experts consumers. This is both expensive and time consuming for from ITU-T Study Group 16 (VCEG) and ISO/IEC JTC 1 the network operators, and is not always possible. Thus SC 29/WG 11 (MPEG). A guiding principle was set for the the efficiency achieved by video compression is becoming development of a “baseline profile” that would be royalty- increasingly important. free: Inthispaper,wepresenttheargumentinfavorofanopen “The JVT codec should have a simple royalty- source, a royalty-free video codec that will keep pace with free “baseline” profile (both on the encoder and the evolution of video traffic. Additionally, we argue that the decoder) in order to promote the wide implemen- availability of a state-of-the-art, royalty-free codec levels the tation and use of the JVT codec. All implementa- playing field, allowing small content owners and application tions should have such a common baseline profile developers to compete with the larger companies that oper- core, in order to allow minimal interoperability ate in this space. This will ultimately result in a richer and among all JVT codecs. The above requirement more diverse internet. means that all technology applied in the baseline profile shall have no IPR, expired IPR, or valid but royalty-fee-free IPR.” [3] Google Inc. 1600 Ampitheatre Parkway, Mountain View, CA 94043, USA However, when it was time to declare IP for this effort, Corresponding author: J. Bankoski multiple participants refused to declare their IP royalty- Email: [email protected] free despite the fact that a majority of IP owners at the Downloaded from https://www.cambridge.org/core. IP address: 170.106.35.229, on 24 Sep 2021 at 16:15:12, subject to the Cambridge Core terms of use, available at https://www.cambridge.org/core/terms. https://doi.org/10.1017/ATSIP.2017.14 1 2 james bankoski et al. time voiced their support. Even though the baseline pro- codec can make a Type-3 declaration, potentially stalling the file performs significantly worse than thehigh” “ and “main” effortorrequiringsignificantworkaround.Evenifallofthe profiles, not all of the IP owners approved its usage for a submissions are accompanied by Type-1 declarations, non- royalty-free baseline. participants may use patents that put royalty free status in MPEG made a further attempt to define a royalty-free question. baseline when in July 2011 they issued a call for proposals Six years after the CfP was issued we still cannot point (CfP) for internet video coding that anticipated that patent to a single published royalty-free standardized codec and declarations associated with the baseline profile would be for those still in the standardization process, it seems very contributed on a royalty-free basis. Each of the resulting unlikely that they will see wider adoption than they already three submissions took a different approach: have today. Independent of the work taking place at MPEG, and at • Web Video Coding (WVC) spun out the Constrained Base- the request of the World Wide Web Consortium (W3C), line profile from AVC/H.264 as an independent standard, in 2011 the Internet Engineering Task Force (IETF) began • Video Coding for Browsers (VCB) is Google’s VP8 video an effort to define a“mandatorytoimplement”(MTI) codec, and, video codec for the WebRTC [5] project that was prefer- • Internet Video Coding (IVC) is built from a base of expired ably royalty-free. WebRTC applications [6]wouldfallback patent IP with new technology added. to use the MTI codec in cases where they are unable to negotiate an alternative, guaranteeing interoperability. WVCwaspublishedin2013andwhilesomeofthepatent AftermuchdebatetwoMTIcodecswereadopted,Google’s holders again refused to license their technology royalty- VP8, and the AVC/H.264 Constrained Baseline profile. free, the hope is that it will become royalty-free once those Bothareinactiveuseandwidelydeployedinmostmajor patents expire in the near future. VCB has been adopted by browsers. MPEG but the status at ISO is uncertain. IVC is nearing OutsideoftheMPEG,therehavebeenacoupleofnotable technical completion. efforts to produce a royalty-free codec. Microsoft published MPEG’s laudable efforts in this area have been hampered their VC-1 codec through SMPTE, but MPEG-LA estab- by the ISO/IEC rules regarding IP declarations. Standards lished a patent pool to collect royalties [7]. Google created bodies are provided with guidance to avoid consideration the WebM project [8] in 2010 after acquiring On2 Technolo- of intellectual property rights (IPR) in technical committees gies [9]. Their VP8 codec is widely deployed, has support in and are asked to let outside organizations (e.g. the World most browsers, and is utilized by many WebRTC applica- Intellectual Property Organization)handlelicensing.The tions, and its successor VP9 continues to achieve adoption only IPR statement participants are asked to make is a patent through its use by companies such as Google/YouTube and declarationthatasksthemtoselectoneofthefollowing Netflix. options [4]: 2.1 The patent holder is willing to negotiate licenses free of charge with other parties on a nondiscriminatory III. STANDARDIZATION basisonreasonabletermsandconditions.Suchnegotia- tions are left to the parties concerned and are performed A) Advantages outside ITU-T/ITU-R/ISO/IEC. (Type-1) 2.2 The patent holder is willing to negotiate licenses with Multimedia standardization ensures interoperability, and other parties on a non-discriminatory basis on reason- the ubiquitous support for content that plays back inde- able terms and conditions. Such negotiations are left pendent of the equipment manufacturer or application ven- to the parties concerned and are performed outside dor. The technical complexity of video codecs makes this ITU-T/ITU-R/ISO/IEC. (Type-2) difficult to achieve. Standards bodies achieve this by: (1) 2.3 The patent holder is not willing to comply with attracting participation from a large cross-section of the the provisions of either paragraph 2.1 or paragraph manufacturing community; (2) having mature development 2.2; in such case, the Recommendation | Deliverable processes; and (3) writing precise and accurate and highly shall not include provisions depending on the patent. scrutinized specification documents. (Type-3) From the perspective of a hardware vendor, standards provide a degree of certainty that the specification will not If a codec is to be considered royalty-free, all technology change that is less obvious when a technology is developed submissionshavetobeaccompaniedbyaType-1 declara- under the control of a single company. Considering the huge tion. However, an intellectual property rights (IPR) holder investment required to implement these standards in hard- gives up certain patent rights when they make a Type-1 ware and the complexity and cost
Load more

Recommended publications
  • Network Working Group A
    Network Working Group A. Filippov Internet Draft Huawei Technologies Intended status: Informational A. Norkin Netflix J.R. Alvarez Huawei Technologies Expires: May 17, 2017 November 17, 2016 <Video Codec Requirements and Evaluation Methodology> draft-ietf-netvc-requirements-04.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. The list of current Internet-Drafts can be accessed at http://datatracker.ietf.org/drafts/current/ Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on May 17, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with <Filippov> Expires May 17, 2017 [Page 1] Internet-Draft Video Codec Requirements and Evaluation November 2016 respect to this document.
    [Show full text]
  • FCC-06-11A1.Pdf
    Federal Communications Commission FCC 06-11 Before the FEDERAL COMMUNICATIONS COMMISSION WASHINGTON, D.C. 20554 In the Matter of ) ) Annual Assessment of the Status of Competition ) MB Docket No. 05-255 in the Market for the Delivery of Video ) Programming ) TWELFTH ANNUAL REPORT Adopted: February 10, 2006 Released: March 3, 2006 Comment Date: April 3, 2006 Reply Comment Date: April 18, 2006 By the Commission: Chairman Martin, Commissioners Copps, Adelstein, and Tate issuing separate statements. TABLE OF CONTENTS Heading Paragraph # I. INTRODUCTION.................................................................................................................................. 1 A. Scope of this Report......................................................................................................................... 2 B. Summary.......................................................................................................................................... 4 1. The Current State of Competition: 2005 ................................................................................... 4 2. General Findings ....................................................................................................................... 6 3. Specific Findings....................................................................................................................... 8 II. COMPETITORS IN THE MARKET FOR THE DELIVERY OF VIDEO PROGRAMMING ......... 27 A. Cable Television Service ..............................................................................................................
    [Show full text]
  • Video Codec Requirements and Evaluation Methodology
    Video Codec Requirements 47pt 30pt and Evaluation Methodology Color::white : LT Medium Font to be used by customers and : Arial www.huawei.com draft-filippov-netvc-requirements-01 Alexey Filippov, Huawei Technologies 35pt Contents Font to be used by customers and partners : • An overview of applications • Requirements 18pt • Evaluation methodology Font to be used by customers • Conclusions and partners : Slide 2 Page 2 35pt Applications Font to be used by customers and partners : • Internet Protocol Television (IPTV) • Video conferencing 18pt • Video sharing Font to be used by customers • Screencasting and partners : • Game streaming • Video monitoring / surveillance Slide 3 35pt Internet Protocol Television (IPTV) Font to be used by customers and partners : • Basic requirements: . Random access to pictures 18pt Random Access Period (RAP) should be kept small enough (approximately, 1-15 seconds); Font to be used by customers . Temporal (frame-rate) scalability; and partners : . Error robustness • Optional requirements: . resolution and quality (SNR) scalability Slide 4 35pt Internet Protocol Television (IPTV) Font to be used by customers and partners : Resolution Frame-rate, fps Picture access mode 2160p (4K),3840x2160 60 RA 18pt 1080p, 1920x1080 24, 50, 60 RA 1080i, 1920x1080 30 (60 fields per second) RA Font to be used by customers and partners : 720p, 1280x720 50, 60 RA 576p (EDTV), 720x576 25, 50 RA 576i (SDTV), 720x576 25, 30 RA 480p (EDTV), 720x480 50, 60 RA 480i (SDTV), 720x480 25, 30 RA Slide 5 35pt Video conferencing Font to be used by customers and partners : • Basic requirements: . Delay should be kept as low as possible 18pt The preferable and maximum delay values should be less than 100 ms and 350 ms, respectively Font to be used by customers .
    [Show full text]
  • DVP Tutorial
    IP Video Conferencing: A Tutorial Roman Sorokin, Jean-Louis Rougier Abstract Video conferencing is a well-established area of communications, which have been studied for decades. Recently this area has received a new impulse due to significantly increased bandwidth of Local and Wide area networks, appearance of low-priced video equipment and development of web based media technologies. This paper presents the main techniques behind the modern IP-based videoconferencing services, with a particular focus on codecs, network protocols, architectures and standardization efforts. Questions of security and topologies are also tackled. A description of a typical video conference scenario is provided, demonstrating how the technologies, responsible for different conference aspects, are working together. Traditional industrial disposition as well as modern innovative approaches are both addressed. Current industry trends are highlighted in respect to the topics, described in the tutorial. Legacy analog/digital technologies, together with the gateways between the traditional and the IP videoconferencing systems, are not considered. Keywords Video Conferencing, codec, SVC, MCU, SIP, RTP Roman Sorokin ALE International, Colombes, France e-mail: [email protected] Jean-Louis Rougier Télécom ParisTech, Paris, France e-mail: [email protected] 1 1 Introduction Video conferencing is a two-way interactive communication, delivered over networks of different nature, which allows people from several locations to participate in a meeting. Conference participants use video conferencing endpoints of different types. Generally a video conference endpoint has a camera and a microphone. The video stream, generated by the camera, and the audio stream, coming from the microphone, are both compressed and sent to the network interface.
    [Show full text]
  • (A/V Codecs) REDCODE RAW (.R3D) ARRIRAW
    What is a Codec? Codec is a portmanteau of either "Compressor-Decompressor" or "Coder-Decoder," which describes a device or program capable of performing transformations on a data stream or signal. Codecs encode a stream or signal for transmission, storage or encryption and decode it for viewing or editing. Codecs are often used in videoconferencing and streaming media solutions. A video codec converts analog video signals from a video camera into digital signals for transmission. It then converts the digital signals back to analog for display. An audio codec converts analog audio signals from a microphone into digital signals for transmission. It then converts the digital signals back to analog for playing. The raw encoded form of audio and video data is often called essence, to distinguish it from the metadata information that together make up the information content of the stream and any "wrapper" data that is then added to aid access to or improve the robustness of the stream. Most codecs are lossy, in order to get a reasonably small file size. There are lossless codecs as well, but for most purposes the almost imperceptible increase in quality is not worth the considerable increase in data size. The main exception is if the data will undergo more processing in the future, in which case the repeated lossy encoding would damage the eventual quality too much. Many multimedia data streams need to contain both audio and video data, and often some form of metadata that permits synchronization of the audio and video. Each of these three streams may be handled by different programs, processes, or hardware; but for the multimedia data stream to be useful in stored or transmitted form, they must be encapsulated together in a container format.
    [Show full text]
  • High Efficiency, Moderate Complexity Video Codec Using Only RF IPR
    Thor High Efficiency, Moderate Complexity Video Codec using only RF IPR draft-fuldseth-netvc-thor-00 Arild Fuldseth, Gisle Bjontegaard (Cisco) IETF 93 – Prague, CZ – July 2015 1 Design principles • Moderate complexity to allow real-time implementation in SW on common HW, as well as new HW designs • Basic building blocks from well-known hybrid approach (motion compensated prediction and transform coding) • Common design elements in modern codecs – Larger block sizes and transforms, up to 64x64 – Quarter pixel interpolation, motion vector prediction, etc. • Cisco RF IPR (note well: declaration filed on draft) – Deblocking, transforms, etc. (some also essential in H.265/4) • Avoid non-RF IPR – If/when others offer RF IPR, design/performance will improve 2 Encoder Architecture Input Transform Quantizer Entropy Output video Coding bitstream - Inverse Transform Intra Frame Prediction Loop filters Inter Frame Prediction Reconstructed Motion Frame Estimation Memory 3 Decoder Architecture Input Entropy Inverse Bitstream Decoding Transform Intra Frame Prediction Loop filters Inter Frame Prediction Output video Reconstructed Frame Memory 4 Block Structure • Super block (SB) 64x64 • Quad-tree split into coding blocks (CB) >= 8x8 • Multiple prediction blocks (PB) per CB • Intra: 1 PB per CB • Inter: 1, 2 (rectangular) or 4 (square) PBs per CB • 1 or 4 transform blocks (TB) per CB 5 Coding-block modes • Intra • Inter0 MV index, no residual information • Inter1 MV index, residual information • Inter2 Explicit motion vector information, residual information
    [Show full text]
  • Encoding H.264 Video for Streaming and Progressive Download
    W4: KEY ENCODING SKILLS, TECHNOLOGIES TECHNIQUES STREAMING MEDIA EAST - 2019 Jan Ozer www.streaminglearningcenter.com [email protected]/ 276-235-8542 @janozer Agenda • Introduction • Lesson 5: How to build encoding • Lesson 1: Delivering to Computers, ladder with objective quality metrics Mobile, OTT, and Smart TVs • Lesson 6: Current status of CMAF • Lesson 2: Codec review • Lesson 7: Delivering with dynamic • Lesson 3: Delivering HEVC over and static packaging HLS • Lesson 4: Per-title encoding Lesson 1: Delivering to Computers, Mobile, OTT, and Smart TVs • Computers • Mobile • OTT • Smart TVs Choosing an ABR Format for Computers • Can be DASH or HLS • Factors • Off-the-shelf player vendor (JW Player, Bitmovin, THEOPlayer, etc.) • Encoding/transcoding vendor Choosing an ABR Format for iOS • Native support (playback in the browser) • HTTP Live Streaming • Playback via an app • Any, including DASH, Smooth, HDS or RTMP Dynamic Streaming iOS Media Support Native App Codecs H.264 (High, Level 4.2), HEVC Any (Main10, Level 5 high) ABR formats HLS Any DRM FairPlay Any Captions CEA-608/708, WebVTT, IMSC1 Any HDR HDR10, DolbyVision ? http://bit.ly/hls_spec_2017 iOS Encoding Ladders H.264 HEVC http://bit.ly/hls_spec_2017 HEVC Hardware Support - iOS 3 % bit.ly/mobile_HEVC http://bit.ly/glob_med_2019 Android: Codec and ABR Format Support Codecs ABR VP8 (2.3+) • Multiple codecs and ABR H.264 (3+) HLS (3+) technologies • Serious cautions about HLS • DASH now close to 97% • HEVC VP9 (4.4+) DASH 4.4+ Via MSE • Main Profile Level 3 – mobile HEVC (5+)
    [Show full text]
  • Max Sound V. Google
    LAW OFFIClS 0~ _,.._.. \'XIALKUP, MELODIA, KELLY & SCHOEN I"ScRGEt<. 2 A PIKlll SSIONAL CORPORA l ION ..... G!JO CALIFORNIA STRE ET, 2611 1~L OO R -' SA N FRANCISCO, CALIFORNIA 94108-2615 (41 5) 901 7210 4 MICHAEL A. KELLY (State Bar #71460) 5 [email protected] MATTHEW D. DAVIS (State Bar #141986) 6 [email protected] KHALDOUN A. BAGHDADI (State Bar #1901 11 ) 7 kbaghdad i@wal kuplawofficc .com 8 JAY W. EISEN HOFER (pro hac vice to be submitted) GEOFFREY C. JARVIS (pro hac vice to be submitted) 9 ADAM J. LEVJTT ,(pro hac vic~ to be submitted) CATHERINE 0 SUILLEABHAfN (pro hac vice to be submitted) 10 GRANT & EISENHOFER P.A. 30 North LaSall e Street, Suite 1200 ll Chicago, Illinois 60602 Tel: (312) 214-0000 12 CHRJSTOPHER M. JOE (pro hac vice to be submitted) 13 ERJC W. BlJETHER (pro hac vice to be submitted) BRIAN A. CARPENTER (State Bar #262349) 14 MARK A. PERANTI E (pro hac vice to be submitted) BUETHER JOE & CARPENTER, LLC 1.5 1700 Pacific, Suite 4750 Dallas, Texas 75201 16 Tel: (214) 466-1272 ATTORNEYS FOR PLAINTIFFS 17 18 TN THE SUPERIOR COURT OF THE STATE OF CALIFORNIA 19 COUNTY OF SANTA CLARA 20 21 MAX SOUND CORPORATION, VSL CaseNo. 114CVI89231 COMMUNICATIONS LTD .. and VEDANTI 22 SYSTEMS LIMITED, UNLIMITED .JURISDICTION 23 Plainti ITs , COMPLAINT FOR DAMAGES AND INJUNCTIVE RELIEF: 24 V. 1. MISAPPROPRIATION OF TRADE SECRETS 25 GOOGLE, INC. , YOUTUBE, LLC , ON2 2. BREACH OF CONTRACT TECHNOLOGIES, IN C., and DOES 1-100, 3. UNFAIR COMPETITION ~ 26 4.
    [Show full text]
  • Netflix and the Development of the Internet Television Network
    Syracuse University SURFACE Dissertations - ALL SURFACE May 2016 Netflix and the Development of the Internet Television Network Laura Osur Syracuse University Follow this and additional works at: https://surface.syr.edu/etd Part of the Social and Behavioral Sciences Commons Recommended Citation Osur, Laura, "Netflix and the Development of the Internet Television Network" (2016). Dissertations - ALL. 448. https://surface.syr.edu/etd/448 This Dissertation is brought to you for free and open access by the SURFACE at SURFACE. It has been accepted for inclusion in Dissertations - ALL by an authorized administrator of SURFACE. For more information, please contact [email protected]. Abstract When Netflix launched in April 1998, Internet video was in its infancy. Eighteen years later, Netflix has developed into the first truly global Internet TV network. Many books have been written about the five broadcast networks – NBC, CBS, ABC, Fox, and the CW – and many about the major cable networks – HBO, CNN, MTV, Nickelodeon, just to name a few – and this is the fitting time to undertake a detailed analysis of how Netflix, as the preeminent Internet TV networks, has come to be. This book, then, combines historical, industrial, and textual analysis to investigate, contextualize, and historicize Netflix's development as an Internet TV network. The book is split into four chapters. The first explores the ways in which Netflix's development during its early years a DVD-by-mail company – 1998-2007, a period I am calling "Netflix as Rental Company" – lay the foundations for the company's future iterations and successes. During this period, Netflix adapted DVD distribution to the Internet, revolutionizing the way viewers receive, watch, and choose content, and built a brand reputation on consumer-centric innovation.
    [Show full text]
  • The H.264 Advanced Video Coding (AVC) Standard
    Whitepaper: The H.264 Advanced Video Coding (AVC) Standard What It Means to Web Camera Performance Introduction A new generation of webcams is hitting the market that makes video conferencing a more lifelike experience for users, thanks to adoption of the breakthrough H.264 standard. This white paper explains some of the key benefits of H.264 encoding and why cameras with this technology should be on the shopping list of every business. The Need for Compression Today, Internet connection rates average in the range of a few megabits per second. While VGA video requires 147 megabits per second (Mbps) of data, full high definition (HD) 1080p video requires almost one gigabit per second of data, as illustrated in Table 1. Table 1. Display Resolution Format Comparison Format Horizontal Pixels Vertical Lines Pixels Megabits per second (Mbps) QVGA 320 240 76,800 37 VGA 640 480 307,200 147 720p 1280 720 921,600 442 1080p 1920 1080 2,073,600 995 Video Compression Techniques Digital video streams, especially at high definition (HD) resolution, represent huge amounts of data. In order to achieve real-time HD resolution over typical Internet connection bandwidths, video compression is required. The amount of compression required to transmit 1080p video over a three megabits per second link is 332:1! Video compression techniques use mathematical algorithms to reduce the amount of data needed to transmit or store video. Lossless Compression Lossless compression changes how data is stored without resulting in any loss of information. Zip files are losslessly compressed so that when they are unzipped, the original files are recovered.
    [Show full text]
  • IP-Soc Shanghai 2017 ALLEGRO Presentation FINAL
    Building an Area-optimized Multi-format Video Encoder IP Tomi Jalonen VP Sales www.allegrodvt.com Allegro DVT Founded in 2003 Privately owned, based in Grenoble (France) Two product lines: 1) Industry de-facto standard video compliance streams Decoder syntax, performance and error resilience streams for H.264|MVC, H.265/SHVC, VP9, AVS2 and AV1 System compliance streams 2) Leading semiconductor video IP Multi-format encoder IP for H.264, H.265, VP9, JPEG Multi-format decoder IP for H.264, H.265, VP9, JPEG WiGig IEEE 802.11ad WDE CODEC IP 2 Evolution of Video Coding Standards International standards defined by standardization bodies such as ITU-T and ISO/IEC H.261 (1990) MPEG-1 (1993) H.262 / MPEG-2 (1995) H.263 (1996) MPEG-4 Part 2 (1999) H.264 / AVC / MPEG-4 Part 10 (2003) H.265 / HEVC (2013) Future Video Coding (“FVC”) MPEG and ISO "Preliminary Joint Call for Evidence on Video Compression with Capability beyond HEVC.” (202?) Incremental improvements of transform-based & motion- compensated hybrid video coding schemes to meet the ever increasing resolution and frame rate requirements 3 Regional Video Standards SMPTE standards in the US VC-1 (2006) VC-2 (2008) China Information Industry Department standards AVS (2005) AVS+ (2012) AVS2.0 (2016) 4 Proprietary Video Formats Sorenson Spark On2 VP6, VP7 RealVideo DivX Popular in the past partly due to technical merits but mainly due to more suitable licensing schemes to a given application than standard video video formats with their patent royalties. 5 Royalty-free Video Formats Xiph.org Foundation
    [Show full text]
  • Efficient Multi-Codec Support for OTT Services: HEVC/H.265 And/Or AV1?
    Efficient Multi-Codec Support for OTT Services: HEVC/H.265 and/or AV1? Christian Timmerer†,‡, Martin Smole‡, and Christopher Mueller‡ ‡Bitmovin Inc., †Alpen-Adria-Universität San Francisco, CA, USA and Klagenfurt, Austria, EU ‡{firstname.lastname}@bitmovin.com, †{firstname.lastname}@itec.aau.at Abstract – The success of HTTP adaptive streaming is un- multiple versions (e.g., different resolutions and bitrates) and disputed and technical standards begin to converge to com- each version is divided into predefined pieces of a few sec- mon formats reducing market fragmentation. However, other onds (typically 2-10s). A client first receives a manifest de- obstacles appear in form of multiple video codecs to be sup- scribing the available content on a server, and then, the client ported in the future, which calls for an efficient multi-codec requests pieces based on its context (e.g., observed available support for over-the-top services. In this paper, we review the bandwidth, buffer status, decoding capabilities). Thus, it is state of the art of HTTP adaptive streaming formats with re- able to adapt the media presentation in a dynamic, adaptive spect to new services and video codecs from a deployment way. perspective. Our findings reveal that multi-codec support is The existing different formats use slightly different ter- inevitable for a successful deployment of today's and future minology. Adopting DASH terminology, the versions are re- services and applications. ferred to as representations and pieces are called segments, which we will use henceforth. The major differences between INTRODUCTION these formats are shown in Table 1. We note a strong differ- entiation in the manifest format and it is expected that both Today's over-the-top (OTT) services account for more than MPEG's media presentation description (MPD) and HLS's 70 percent of the internet traffic and this number is expected playlist (m3u8) will coexist at least for some time.
    [Show full text]