DOCSLIB.ORG

Enhancing Libva-Utils with VP8 and HEVC Encoding and Temporal Scalability for VP8

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Enhancing Libva-Utils with VP8 and HEVC Encoding and Temporal Scalability for VP8 Title: Enhancing Libva-Utils with VP8 and HEVC Encoding and Temporal Scalability for VP8 = Context = Many modern CPUs support hardware acceleration for processing, decoding and encoding video. Hardware acceleration lowers the CPU time needed for handling videos, and it can also be more energy-efficient, resulting in longer battery life for mobile devices. Applications can leverage these capabilities with interfaces that enable access to hardware acceleration from user mode. For Intel CPUs on Linux, this interface is called VA-API. It consists of “a main library and driver- specific acceleration backends for each supported hardware vendor” [1]. The main library is called libva, and the driver-specific backend for integrated Intel GPUs is called intel-vaapi-driver. In this project, I want to focus on libva-utils, written in C. It provides simple reference applications for encoding, decoding and video processing and includes a number of API conformance tests for libva (which are implemented using the GoogleTest framework). Libva-utils is designed to test the hardware acceleration and API stack and serves as a starting point for further development, such as including VA-API acceleration into application software and multimedia frameworks. = Problem = As hardware advances, VA-API must reflect these changes. Most available engineering resources are invested in the backend (intel-vaapi-driver) and the main library (libva). Regarding libva-utils, several areas can be identified that have lagged behind the other parts of this stack. Libva-utils in its current state does not include reference encoders for either VP8 or HEVC. Further encoder-specific enhancements such as temporal scalability are currently only available to selected codecs (e.g., H.264). With this present proposal, I intend to contribute to an up-to-date libva-utils. = Project Goals/Deliverables = * Implement a sample encoder application for the VP8 codec (called vp8enc). * Implement a sample encoder application for the HEVC codec (called hevcenc). * Add automated testing * Add temporal scalability to VP8 encoder. * Optional: Add temporal scalability VP9 encoder. = Prerequisites = VP8 and HEVC encoding are supported on Intel Gen9 GPUs and higher; therefore, a Skylake+ system is needed for development and testing. I plan to install a low-cost remotely accessible Kabylake Celeron Server running a recent version of 64-bit Ubuntu as the main development machine for this project. On the software side, having a self-contained stack with intel-vaapi-driver, libva and libva-utils would allow different versions to be tested independently. The entire stack should be compiled in a way that all relevant shared libraries, such as libva*.so and libi965_drv_video.so, can be placed in arbitrary locations. This can be done by setting relevant environment variables (such as LIBVA_LIBS at compile time, respectively LIBVA_DRIVERS_PATH at runtime). This allows a coexistence with standard Ubuntu packages and multiple versions of the stack on the same machine. = Implementation = == VP8 Encoder Application == Developing a simple VP8 encoder application demands a basic understanding of the VP8 codec [2], its bitstream [3], the IVF container [4] and VAAPI. Because we are interfacing a hardware encoder and since most of the intra-frame processing is transparent to the user, it is not necessary to understand every detail of the VP8 codec. Nevertheless, we must know how VP8 handles inter- frame processing because we must provide the necessary buffers for the reference frames. Libva-utils already includes a reference implementation of a VP9 encoder application [5], which can be used as a starting point to prototype a VP8 encoder. To understand which parts of the code need modification, it is worth investigating the differences between VP8 and VP9. The following list is a first attempt to identify these differences, but it may not currently be complete: * Superblocks and Macroblocks VP8 processes a frame in fixed-sized macroblocks (for example, 4x4 luma and 8x8 chroma). VP9 uses a more granular approach—it uses so-called superblocks, of sizes up to 64x64 pixels. Superblocks can be further subdivided into smaller entities down to 4x4 pixels. This helps VP9 perform better with high-resolution content. For example, imagine encoding a uniformly blue sky. The corresponding blocks do not hold much frequency information and can therefore be encoded more efficiently in a large block. Having a brief look at the source of vp9enc.c, I am inclined to assume that by using VAAPI, this difference is transparent to the user. * Segments Both codecs support segment frames. This means that each macroblock or superblock can be individually assigned to a segment number. The segments need not be contiguous or have any predefined order [6]. Each segment can be processed with its own quantization and filter settings. VP8 and VP9 differ in the number of maximum supported segments per frame. VP8 allows for four segments and VP9 allows for eight segments. In libva, VP8 and VP9 segments are allocated slightly differently, as one can see when comparing va_enc_vp8.h and va_enc_vp9.h, and therefore some adaptation work in this regard can be expected. * Reference Frames Both codecs use reference frames. VP8- and VP9-encoded frames can have up to three references (the last frame, the golden frame and an alternative reference frame). In VP9, potential reference frames are stored in a pool of eight frames. For example, in va_enc_vp9.h, the _VAEncPictureParameterBufferVP9 structure holds an element VASurfaceID reference_frames[8]. Currently, I am unsure whether the VP8 implementation uses such a pool. Regardless, reference frames are treated slightly differently. Generally speaking, reference frames are part of the inter- frame processing, and as frames must be allocated (by calling vaCreateSurfaces()), it is certain that this part of the VP8 encoder application must be reworked. * Tiles and Data Partitioning VP9 uses tiling to divide frames into sections, which can be processed independently. VP8 uses data partitioning, allowing to binary code macroblocks and motion vectors independently from quantized transformation coefficients. Both techniques address the need to parallelize work across several CPU cores. VP8 does not support tiling and VP9 does not support data partitioning. Implementing data partitioning for the VP8 encoder application can most likely be done by setting the auto_partitions flag in the _VAEncPictureParameterBufferVP8 structure. Developing the VP8 encoder application can be done in incremental steps. This process would start with an I–Frame-only encoder and later add support for segments and reference frames and VP8- specific features such as data partitioning. == HEVC Encoder Application == Like for the previous task, the prerequisites for developing a simple HEVC encoder application are a basic understanding of the HEVC codec [7], its bitstream and container, as well as the corresponding VAAPI. For reference, an H.264 encoder is already available in libva-utils. Studying other sources such as libyami [8] and gstreamer-vaapi [9] may be worthwhile. Comparing H.264 to HEVC can hint to which parts of the implementation require special attention: * Macroblocks and Coding Tree Units H.264 uses fixed-sized macroblocks for encoding (size depends on the used profile and whether luma or chroma is handled, and it can vary between 4x4, 8x8 and 16x16). HEVC (like VP9) addresses the need for high-resolution content. HEVC approaches this by dividing the frame into coding tree units (CTUs), “which can use larger block structures of up to 64×64 pixels and can better sub-partition the picture into variable sized structures” [10]. The structure of the HEVC coding tree is a quadtree, each subdivision of which has four children. The smallest CTU has a size of 4x4. My guess is that this is internally handled and the encoder application need not interfere at this level. * Prediction Modes In HEVC, the number of available prediction modes has increased to 35 (from nine for H.264). Again, this difference is most likely internally handled. * Reference Frames H.264 can have up to 16 reference frames, whereas in HEVC, the number of references is 2x8, meaning that the same reference frame can be used more than once but with different weights. The total number of unique references in HEVC is eight. * Others This list is certainly not complete at this time. In addition, more research on HEVC, its bitstream and container is required. The time needed to become familiar with both codecs is reserved in the timeline. == Automated Encoder Test == To test the developed encoders automatically, the following criteria for encoder output can be evaluated: * Decodability: tests whether the bitstream can be decoded without errors * Number of frames: checks whether the number of input frames equals the number of output frames * Resolution: checks whether input and output resolutions match * Frame content: tests for content reproduction All tests demand the availability of a corresponding decoder, either from within libva-utils or an external decoder. Testing frame content is a bit more complicated, as this test includes the generation of suitable test patterns, encoding, decoding and automated analysis of the test pattern. I would like to propose the use of QR codes as a test pattern that is simple both to generate and to analyze. Because we are testing lossy codecs, the QR dots must be the size of a macroblock (or an integer multiple) to keep distortion resulting from the coding process low. Depending on the QR profile used, a certain percentage of dot defects can also be tolerated (7–30%) Rather than quantifying the quality of the resulting image, this test is limited to basic image reproduction and only qualifies as a pass/fail test. This test could be extended in two ways: * Testing interframe encoding by using a series of QR codes While this test is intended for static images, it can be enhanced to handle interframe encoding by using a series of QR codes. For example, the frame number (such as “frame:%03d”) can be encoded into each QR code.
Load more

Recommended publications
  • Enabling Hardware Accelerated Video Decode on Intel® Atom™ Processor D2000 and N2000 Series Under Fedora 16
    Enabling Hardware Accelerated Video Decode on Intel® Atom™ Processor D2000 and N2000 Series under Fedora 16 Application Note October 2012 Order Number: 509577-003US INFORMATIONLegal Lines and Disclaimers IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. A “Mission Critical Application” is any application in which failure of the Intel Product could result, directly or indirectly, in personal injury or death. SHOULD YOU PURCHASE OR USE INTEL'S PRODUCTS FOR ANY SUCH MISSION CRITICAL APPLICATION, YOU SHALL INDEMNIFY AND HOLD INTEL AND ITS SUBSIDIARIES, SUBCONTRACTORS AND AFFILIATES, AND THE DIRECTORS, OFFICERS, AND EMPLOYEES OF EACH, HARMLESS AGAINST ALL CLAIMS COSTS, DAMAGES, AND EXPENSES AND REASONABLE ATTORNEYS' FEES ARISING OUT OF, DIRECTLY OR INDIRECTLY, ANY CLAIM OF PRODUCT LIABILITY, PERSONAL INJURY, OR DEATH ARISING IN ANY WAY OUT OF SUCH MISSION CRITICAL APPLICATION, WHETHER OR NOT INTEL OR ITS SUBCONTRACTOR WAS NEGLIGENT IN THE DESIGN, MANUFACTURE, OR WARNING OF THE INTEL PRODUCT OR ANY OF ITS PARTS. Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked “reserved” or “undefined”.
    [Show full text]
  • ROS Robotics by Example Second Edition
    ROS Robotics By Example Second Edition Learning to control wheeled, limbed, and flying robots using ROS Kinetic Kame Carol Fairchild Dr. Thomas L. Harman BIRMINGHAM - MUMBAI ROS Robotics By Example Second Edition Copyright © 2017 Packt Publishing All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews. Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book. Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information. First published: June 2016 Second edition: November 2017 Production reference: 1301117 Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK. ISBN 978-1-78847-959-2 www.packtpub.com Credits Authors Copy Editor Carol Fairchild Safis Editing Dr. Thomas L. Harman Proofreader Reviewer Safis Editing Lentin Joseph Indexer Acquisition Editor Aishwarya Gangawane Frank Pohlmann Graphics Project Editor Kirk D'Penha Alish Firasta Production Coordinator Content Development Editor Nilesh Mohite Venugopal Commuri Technical Editor Bhagyashree Rai About the Authors Carol Fairchild is the owner and principal engineer of Fairchild Robotics, a robotics development and integration company.
    [Show full text]
  • Release Notes for Debian 11 (Bullseye), 64-Bit PC
    Release Notes for Debian 11 (bullseye), 64-bit PC The Debian Documentation Project (https://www.debian.org/doc/) October 1, 2021 Release Notes for Debian 11 (bullseye), 64-bit PC This document is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License, version 2, as published by the Free Software Foundation. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. The license text can also be found at https://www.gnu.org/licenses/gpl-2.0.html and /usr/ share/common-licenses/GPL-2 on Debian systems. ii Contents 1 Introduction 1 1.1 Reporting bugs on this document . 1 1.2 Contributing upgrade reports . 1 1.3 Sources for this document . 2 2 What’s new in Debian 11 3 2.1 Supported architectures . 3 2.2 What’s new in the distribution? . 3 2.2.1 Desktops and well known packages . 3 2.2.2 Driverless scanning and printing . 4 2.2.2.1 CUPS and driverless printing . 4 2.2.2.2 SANE and driverless scanning . 4 2.2.3 New generic open command . 5 2.2.4 Control groups v2 . 5 2.2.5 Persistent systemd journal .
    [Show full text]
  • A/300, "ATSC 3.0 System Standard"
    ATSC A/300:2017 ATSC 3.0 System 19 October 2017 ATSC Standard: ATSC 3.0 System (A/300) Doc. A/300:2017 19 October 2017 Advanced Television Systems Committee 1776 K Street, N.W. Washington, DC 20006 202-872-9160 i ATSC A/300:2017 ATSC 3.0 System 19 October 2017 The Advanced Television Systems Committee, Inc., is an international, non-profit organization developing voluntary standards for digital television. The ATSC member organizations represent the broadcast, broadcast equipment, motion picture, consumer electronics, computer, cable, satellite, and semiconductor industries. Specifically, ATSC is working to coordinate television standards among different communications media focusing on digital television, interactive systems, and broadband multimedia communications. ATSC is also developing digital television implementation strategies and presenting educational seminars on the ATSC standards. ATSC was formed in 1982 by the member organizations of the Joint Committee on InterSociety Coordination (JCIC): the Electronic Industries Association (EIA), the Institute of Electrical and Electronic Engineers (IEEE), the National Association of Broadcasters (NAB), the National Cable Telecommunications Association (NCTA), and the Society of Motion Picture and Television Engineers (SMPTE). Currently, there are approximately 120 members representing the broadcast, broadcast equipment, motion picture, consumer electronics, computer, cable, satellite, and semiconductor industries. ATSC Digital TV Standards include digital high definition television (HDTV), standard definition television (SDTV), data broadcasting, multichannel surround-sound audio, and satellite direct-to-home broadcasting. Note: The user’s attention is called to the possibility that compliance with this standard may require use of an invention covered by patent rights. By publication of this standard, no position is taken with respect to the validity of this claim or of any patent rights in connection therewith.
    [Show full text]
  • Video Compression Optimized for Racing Drones
    Video compression optimized for racing drones Henrik Theolin Computer Science and Engineering, master's level 2018 Luleå University of Technology Department of Computer Science, Electrical and Space Engineering Video compression optimized for racing drones November 10, 2018 Preface To my wife and son always! Without you I'd never try to become smarter. Thanks to my supervisor Staffan Johansson at Neava for providing room, tools and the guidance needed to perform this thesis. To my examiner Rickard Nilsson for helping me focus on the task and reminding me of the time-limit to complete the report. i of ii Video compression optimized for racing drones November 10, 2018 Abstract This thesis is a report on the findings of different video coding tech- niques and their suitability for a low powered lightweight system mounted on a racing drone. Low latency, high consistency and a robust video stream is of the utmost importance. The literature consists of multiple comparisons and reports on the efficiency for the most commonly used video compression algorithms. These reports and findings are mainly not used on a low latency system but are testing in a laboratory environment with settings unusable for a real-time system. The literature that deals with low latency video streaming and network instability shows that only a limited set of each compression algorithms are available to ensure low complexity and no added delay to the coding process. The findings re- sulted in that AVC/H.264 was the most suited compression algorithm and more precise the x264 implementation was the most optimized to be able to perform well on the low powered system.
    [Show full text]
  • (12) United States Patent (10) Patent No.: US 8,654,842 B2 Ganesh Et Al
    USOO8654842B2 (12) United States Patent (10) Patent No.: US 8,654,842 B2 Ganesh et al. (45) Date of Patent: Feb. 18, 2014 (54) ACCELERATED VIDEO ENCODING 6,044,408 A 3/2000 Engstrom et al. 6,101,276 A 8, 2000 Adiletta et al. 6,128,026 A 10/2000 Brothers, III (75) Inventors: SNESN RWSRS 6,252,905 B1 6/2001 Pokrinchak et al. onald J. Yunsil, Kirkland, (US); 6,434,196 B1* 8/2002 Sethuraman et al. ... 375/240. 12 Gary J. Sullivan, Redmond, WA (US); 6,721,359 B1 4/2004 Bist et al. Glenn F. Evans, Kirkland, WA (US); (Continued) Shyam Sadhwani, Bellevue, WA (US); Stephen J. Estrop, Carnation, WA (US) FOREIGN PATENT DOCUMENTS (73) Assignee: Microsoft Corporation, Redmond, WA EP 1347,650 9, 2003 (US) WO WOO2O7446 A2 1, 2001 WO WOO219095 3, 2002 (*) Notice: Subject to any disclaimer, the term of this OTHER PUBLICATIONS patent is extended or adjusted under 35 U.S.C. 154(b) by 1651 days. Rossi, “Multicore Signal Processing Platform with Heterogeneous Configurable Hardware Accelerators', 2013, IEEE, p. 1-14.* (21) Appl. No.: 11/673,423 (Continued) (22) Filed: Feb. 9, 2007 Primary Examiner — Taghi Arani (65) Prior Publication Data Assistant Examiner — Gregory Lane (74) Attorney, Agent, or Firm — Carole A Boelitz: Raghu US 2007/O2O1562 A1 Aug. 30, 2007 Chinagudabha; Micky Minhas Related U.S. Application Data (57) ABSTRACT (63) Continuation-in-part of application No. 1 1/276,336, A video encoding acceleration service to increase one or filed on Feb. 24, 2006. more of the speed and quality of video encoding is described.
    [Show full text]
  • Recommendation Itu-R Bt.1833-2*, **
    Recommendation ITU-R BT.1833-2 (08/2012) Broadcasting of multimedia and data applications for mobile reception by handheld receivers BT Series Broadcasting service (television) ii Rec. ITU-R BT.1833-2 Foreword The role of the Radiocommunication Sector is to ensure the rational, equitable, efficient and economical use of the radio-frequency spectrum by all radiocommunication services, including satellite services, and carry out studies without limit of frequency range on the basis of which Recommendations are adopted. The regulatory and policy functions of the Radiocommunication Sector are performed by World and Regional Radiocommunication Conferences and Radiocommunication Assemblies supported by Study Groups. Policy on Intellectual Property Right (IPR) ITU-R policy on IPR is described in the Common Patent Policy for ITU-T/ITU-R/ISO/IEC referenced in Annex 1 of Resolution ITU-R 1. Forms to be used for the submission of patent statements and licensing declarations by patent holders are available from http://www.itu.int/ITU-R/go/patents/en where the Guidelines for Implementation of the Common Patent Policy for ITU-T/ITU-R/ISO/IEC and the ITU-R patent information database can also be found. Series of ITU-R Recommendations (Also available online at http://www.itu.int/publ/R-REC/en) Series Title BO Satellite delivery BR Recording for production, archival and play-out; film for television BS Broadcasting service (sound) BT Broadcasting service (television) F Fixed service M Mobile, radiodetermination, amateur and related satellite services P Radiowave propagation RA Radio astronomy RS Remote sensing systems S Fixed-satellite service SA Space applications and meteorology SF Frequency sharing and coordination between fixed-satellite and fixed service systems SM Spectrum management SNG Satellite news gathering TF Time signals and frequency standards emissions V Vocabulary and related subjects Note: This ITU-R Recommendation was approved in English under the procedure detailed in Resolution ITU-R 1.
    [Show full text]
  • The H.264/MPEG4 Advanced Video Coding Standard and Its Applications
    SULLIVAN LAYOUT 7/19/06 10:38 AM Page 134 STANDARDS REPORT The H.264/MPEG4 Advanced Video Coding Standard and its Applications Detlev Marpe and Thomas Wiegand, Heinrich Hertz Institute (HHI), Gary J. Sullivan, Microsoft Corporation ABSTRACT Regarding these challenges, H.264/MPEG4 Advanced Video Coding (AVC) [4], as the latest H.264/MPEG4-AVC is the latest video cod- entry of international video coding standards, ing standard of the ITU-T Video Coding Experts has demonstrated significantly improved coding Group (VCEG) and the ISO/IEC Moving Pic- efficiency, substantially enhanced error robust- ture Experts Group (MPEG). H.264/MPEG4- ness, and increased flexibility and scope of appli- AVC has recently become the most widely cability relative to its predecessors [5]. A recently accepted video coding standard since the deploy- added amendment to H.264/MPEG4-AVC, the ment of MPEG2 at the dawn of digital televi- so-called fidelity range extensions (FRExt) [6], sion, and it may soon overtake MPEG2 in further broaden the application domain of the common use. It covers all common video appli- new standard toward areas like professional con- cations ranging from mobile services and video- tribution, distribution, or studio/post production. conferencing to IPTV, HDTV, and HD video Another set of extensions for scalable video cod- storage. This article discusses the technology ing (SVC) is currently being designed [7, 8], aim- behind the new H.264/MPEG4-AVC standard, ing at a functionality that allows the focusing on the main distinct features of its core reconstruction of video signals with lower spatio- coding technology and its first set of extensions, temporal resolution or lower quality from parts known as the fidelity range extensions (FRExt).
    [Show full text]
  • RULING CODECS of VIDEO COMPRESSION and ITS FUTURE 1Dr.Manju.V.C, 2Apsara and 3Annapoorna
    International Journal of Application or Innovation in Engineering & Management (IJAIEM) Web Site: www.ijaiem.org Email: [email protected] Volume 8, Issue 7, July 2019 ISSN 2319 - 4847 RULING CODECS OF VIDEO COMPRESSION AND ITS FUTURE 1Dr.Manju.v.C, 2Apsara and 3Annapoorna 1Professor,KSIT 2Under-Gradute, Telecommunication Engineering, KSIT 3Under-Gradute, Telecommunication Engineering, KSIT Abstract Development of economical video codecs for low bitrate video transmission with higher compression potency has been a vigorous space of analysis over past years and varied techniques are projected to fulfill this need. Video Compression is a term accustomed outline a technique for reducing the information accustomed cipher digital video content. This reduction in knowledge interprets to edges like smaller storage needs and lower transmission information measure needs, for a clip of video content. In this paper, we survey different video codec standards and also discuss about the challenges in VP9 codec Keywords: Codecs, HEVC, VP9, AV1 1. INTRODUCTION Storing video requires a lot of storage space. To make this task manageable, video compression technology was developed to compress video, also known as a codec. Video coding techniques provide economic solutions to represent video data in a more compact and stout way so that the storage and transmission of video will be completed in less value in less cost in terms of bandwidth, size and power consumption. This technology (video compression) reduces redundancies in spatial and temporal directions. Spatial reduction physically reduces the size of the video data by selectively discarding up to a fourth or more of unneeded parts of the original data in a frame [1].
    [Show full text]
  • An Efficient Spatial Scalable Video Encoder Based on DWT
    An Efficient Spatial Scalable Video Encoder Based on DWT Saoussen Cheikhrouhou1, Yousra Ben Jemaa2, Mohamed Ali Ben Ayed1, and Nouri Masmoudi1 1 Laboratory of Electronics and Information Technology Sfax National School of Engineering, BP W 3038, Sfax, Tunisia 2 Signal and System Unit, ENIT, Tunisia [email protected] Abstract. Multimedia applications reach a dramatic increase in nowadays life. Therefore, video coding scalability is more and more desirable. Spatial scalability allows the adaptation of the bit-stream to end users as well as varying terminal capabilities. This paper presents a new Discrete Wavelet Transform (DWT) based coding scheme, which offers spatial scalability from one hand and ensures a simple hardware implementation compared to the other predictive scalable compression techniques from the other. Experimental results have shown that our new compression scheme offers also good compression efficiency. Indeed, it achieves up to 61\% of bit-rate saving for Common Intermediate Format (CIF) sequences using lossy compression and up to 57\% using lossless compression compared with the Motion JPEG2000 standard and 64\% compared with a DWT- coder based on Embedded Zero tree Wavelet (EZW) entropy encoder. Keywords: video conference, temporal redundancy, spatial scalability, discrete wavelet transform dwt, tier1 and tier2 entropy coding. 1 Introduction Advances in video coding technology are enabling an increasing number of video applications ranging from multimedia messaging, and video conferencing to standard and high-definition TV broadcasting. Furthermore, video content is delivered to a variety of decoding devices with heterogeneous display and computational capabilities [1]. In these heterogeneous environments, flexible adaptation of once- encoded content is desirable.
    [Show full text]
  • An Analysis of VP8, a New Video Codec for the Web Sean Cassidy
    Rochester Institute of Technology RIT Scholar Works Theses Thesis/Dissertation Collections 11-1-2011 An Analysis of VP8, a new video codec for the web Sean Cassidy Follow this and additional works at: http://scholarworks.rit.edu/theses Recommended Citation Cassidy, Sean, "An Analysis of VP8, a new video codec for the web" (2011). Thesis. Rochester Institute of Technology. Accessed from This Thesis is brought to you for free and open access by the Thesis/Dissertation Collections at RIT Scholar Works. It has been accepted for inclusion in Theses by an authorized administrator of RIT Scholar Works. For more information, please contact [email protected]. An Analysis of VP8, a New Video Codec for the Web by Sean A. Cassidy A Thesis Submitted in Partial Fulfillment of the Requirements for the Degree of Master of Science in Computer Engineering Supervised by Professor Dr. Andres Kwasinski Department of Computer Engineering Rochester Institute of Technology Rochester, NY November, 2011 Approved by: Dr. Andres Kwasinski R.I.T. Dept. of Computer Engineering Dr. Marcin Łukowiak R.I.T. Dept. of Computer Engineering Dr. Muhammad Shaaban R.I.T. Dept. of Computer Engineering Thesis Release Permission Form Rochester Institute of Technology Kate Gleason College of Engineering Title: An Analysis of VP8, a New Video Codec for the Web I, Sean A. Cassidy, hereby grant permission to the Wallace Memorial Library to repro- duce my thesis in whole or part. Sean A. Cassidy Date i Acknowledgements I would like to thank my thesis advisors, Dr. Andres Kwasinski, Dr. Marcin Łukowiak, and Dr. Muhammad Shaaban for their suggestions, advice, and support.
    [Show full text]
  • PC Hardware Contents
    PC Hardware Contents 1 Computer hardware 1 1.1 Von Neumann architecture ...................................... 1 1.2 Sales .................................................. 1 1.3 Different systems ........................................... 2 1.3.1 Personal computer ...................................... 2 1.3.2 Mainframe computer ..................................... 3 1.3.3 Departmental computing ................................... 4 1.3.4 Supercomputer ........................................ 4 1.4 See also ................................................ 4 1.5 References ............................................... 4 1.6 External links ............................................. 4 2 Central processing unit 5 2.1 History ................................................. 5 2.1.1 Transistor and integrated circuit CPUs ............................ 6 2.1.2 Microprocessors ....................................... 7 2.2 Operation ............................................... 8 2.2.1 Fetch ............................................. 8 2.2.2 Decode ............................................ 8 2.2.3 Execute ............................................ 9 2.3 Design and implementation ...................................... 9 2.3.1 Control unit .......................................... 9 2.3.2 Arithmetic logic unit ..................................... 9 2.3.3 Integer range ......................................... 10 2.3.4 Clock rate ........................................... 10 2.3.5 Parallelism .........................................
    [Show full text]