1. 程式人生 > >H264幀內編碼與幀間編碼

H264幀內編碼與幀間編碼

晚上沒事幹,無聊,所以想寫點什麼。

為了達到節約空間的目的,視訊影象都是經過編碼,然後用於各種不同的場合,特別是網路傳輸,因為頻寬的限制,為了更好的傳輸資料,必須對視訊進行壓縮處理。而目前最流行的當屬H264了。

經過H264壓縮的視訊,可分為I、B、P三種不同的幀。其中I幀因為不參考其他幀,所以是幀內編碼。P幀,要前向參考,而B幀,則要進行雙向參考,這兩種,都屬於幀間編碼。

先說說幀內編碼:

幀內,顧名思義,就是不求外,只求內。不管外部資料如何,僅僅通過自身已有的資料進行編碼。一幅影象裡面的物體往往具有空間上的相關性,比如,以下圖片:

除了中間的幾個字,其他區域都是藍色的,並且是一模一樣的,所以,在空間上,資料就有相當大的冗餘。而幀內編碼,就是要去除這部分冗餘資料。在幀內編碼情況下,編碼影象僅僅進過DCT(離散餘弦變換)、量化器唄編碼器就可生成編碼位元流。DCT直接用於原始資料。

下面來說說幀間編碼:

視訊,其實就是一張一張圖片而已,而這些圖片其實都是相似的,僅僅只有很小的區別,這樣就可以達到欺騙我們肉眼的效果,給我們一種動畫的感覺。而這,就是所謂的時間相關性。比如上圖,如果我們把它想象成一個視訊,Media這個單詞在裡面運動,不管Media運動到哪裡,他始終都是Media這個單詞,樣子都沒有任何變化,僅僅是位置變了。而變化量、方向,我們可以用一個矢量表示,這就是所謂的運動向量。幀間編碼與幀內編碼的不同之處在於他經過預測環節的處理。步驟如下:

1、計算參考幀與原始幀之間的運動向量

2、通過參考幀與運動向量生成原始幀的預測影象

3、講原始影象與預測畫素差值生成差分影象資料

4、對差分影象資料進行DCT變換

5、經過量化器量化

6、編碼器生成壓縮資料

以上就是筆者對編碼的意見簡單的理解,後面再有無聊的時候,會對這幾個步驟做一些詳細的分析

相關推薦

H264編碼編碼

晚上沒事幹,無聊,所以想寫點什麼。 為了達到節約空間的目的,視訊影象都是經過編碼,然後用於各種不同的場合,特別是網路傳輸,因為頻寬的限制,為了更好的傳輸資料,必須對視訊進行壓縮處理。而目前最流行的當屬H264了。 經過H264壓縮的視訊,可分為I、B、P三種不同的幀。其中

25組-對項目需求的理解以及組討論合作

分享 采集 開發app 9.png right 組成 成員 之間 接受  經過昨天對需求文檔的分析評審,我們初步明確了項目的需求。   1.用戶可以選擇上位機與CANTool裝置連接的串口號(上位機可以搜索到可使用的串口號)   2.用戶可以通過GUI界面間接的設置CANT

Python3中字符串的編碼解碼以及編碼之間轉換(decode、encode)

python3 encode 由於 表示 nic code .... 以及 mage 一、編碼 二、編碼與解碼 Python3中對py文件的默認編碼是urf-8。但是字符串的編碼是Unicode。 由於Unicode采用32位4個字節來表示一個字符,存儲和傳輸太浪費資

字串編碼Python 3編碼

昨天部落格訪問量超過20w了,很高興,也希望這些筆記和文章能夠真正幫到更多的人。對於一個做技術的人來說,分享真的會給自己帶來很多快樂。不過說來也很慚愧,最近兩個月都沒寫什麼新的內容,一直忙於畢業設計和論文的事,也沒學什麼新的東西。不過想到馬上要畢業將要踏上新的征

iOS百度地圖簡單應用( iOS地圖定位(定位、地理編碼反地理編碼、mapView、大頭針)

匯入百度SDK 注:自iOS8起,系統定位功能進行了升級,SDK為了實現最新的適配,自v2.5.0起也做了相應的修改,開發者在使用定位功能之前,需要在info.plist裡新增(以下二選一,兩個都新增預設使用NSLocationWhenInUseUsageDescrip

百度地圖----地理編碼反地理編碼

百度地圖—-地理編碼與反地理編碼 ONE Goal,ONE Passion ! 地理編碼: 地理編碼—-就是將我們熟悉的地址解析為經緯度.如: 地址 LatLng(座標)

Android 百度地圖api地理編碼逆地理編碼

    何為地理編碼?何為逆地理編碼? 地理編碼:即地址解析,由詳細到街道的結構化地址得到百度經緯度資訊。 逆地理編碼:即逆地址解析,由百度經緯度資訊得到結構化地址資訊。 然後鄙視一下百度地圖a

VVC/VTM編碼主要流程圖劃分函式

(1)VTM中幀內編碼程式的主要流程如下,進行劃分的主要函式是XCompressCU與xCheckModeSpilt (2)xCompressCU函式的主體部分如下。對於幀內編碼來說,在xCompressCU函式中主要進行的就是一個模式的分割以及幀內代價的計算,通常在填充分割模式時都會先填充ETM_IN

【HEVC學習研究】42、HEVC編碼的原理和實現(下)

4、編碼幀內預測模式 大量增加可選擇的預測模式可以提供更高的編碼效率,同時要求編碼預測模式有更加高效的方法降低更多模式帶來的負擔。與H.264採用一個最可能模式不同的是,對於亮度分量,三個最可能模式用於預測實際的幀內預測模式。同時,也考慮了三個最可能模式中的冗餘資訊,重複的

【HEVC學習研究】39、HEVC編碼的原理和實現(上)

【前面N篇博文都講了一些HEVC幀內預測的程式碼結構和簡單的方法,但是尚未對整體的演算法和實現做一個比較完整的描述。本篇藉助參考文獻《High Efficiency Video Coding (HEVC) -- Algorithms and Architectures》的

HEVC演算法和體系結構:預測編碼預測

<link rel="stylesheet" href="https://csdnimg.cn/release/phoenix/template/css/

ffmpeg libx264視訊編碼過程中預測模式a->i_predict4x4[idx]的獲取問題

analyse.c的函式static void x264_mb_analyse_intra(...)中有這麼一段程式碼: if( i_best > 0 )  //註釋來自leixiaohua大神                 {                 

33、編碼一個CU(部分)2、預測各種模式的實現

HEVC中一共定義了35中幀內編碼預測模式,編號分別以0-34定義。其中模式0定義為平面模式(INTRA_PLANAR),模式1定義為均值模式(INTRA_DC),模式2~34定義為角度預測模式(INTRA_ANGULAR2~INTRA_ANGULAR34),分別代表了不同

HEVC函式入門(2)——編碼一個CU

這裡依然整理自http://blog.csdn.net/shaqoneal/article/details/37500715 且閱讀CU這部分主要對我而言是為了QP。另外一個方向是Tile不要迷失啦!!! 提醒我自己看http://blog.csdn.net

MediaCodec 編碼H264 編碼後dequeueOutputBuffer為-1的問題

在用android MediaCodec編碼h264的時候,會遇到,dequeueOutputBuffer在成功獲取到config幀(sps pps)及第一個I幀後,dequeueOutputBuffer然後結果一直為-1的情況, 在我用的三星note3及小米3都是這樣的

H.264預測編碼預測

預測編碼是視訊壓縮中最基本的編碼工具,常見的預測編碼為幀間預測和幀內預測。 視訊編碼中,主要的冗餘資訊是時間冗餘,其次是空間冗餘,視訊編碼通過幀間預測消除時間冗餘,通過幀內預測消除空間冗餘。接下來說說

x265一個CU的編碼過程(版本2.8)

一. 幀內CU、PU、TU:  1. CU:編碼單元,在幀內只有  64x64-8x8; 2. PU:預測單元,幀內有2Nx2N、NxN兩種劃分方式,其中2Nx2N對應所屬編碼單元CU的尺寸,而NxN只存在於8x8的CU中,              因為對於其他尺寸的

[編碼]概分法編碼快速判定

曾經有在讀研究生問我有關幀間編碼快速判定演算法,因為他(她)目前的任務主要是為幀間編碼或者幀內編碼提出一種實用實時的快速演算法。對於實時編碼軟體(或者硬體)而言包括X264,T264在內為了達快速的效果,以達到實時傳送影象資訊的效果,都會採用快速判定幀間或者幀內預測,有的會去掉一些複雜的演算法。主要的想法就是

H.264預測編碼預測

預測編碼是視訊壓縮中最基本的編碼工具,常見的預測編碼為幀間預測和幀內預測。 視訊編碼中,主要的冗餘資訊是時間冗餘,其次是空間冗餘,視訊編碼通過幀間預測消除時間冗餘,通過幀內預測消除空間冗餘。接下來

javacv + rtsp +ffmpge 設定編碼格式

private boolean isStart = true; public void frameRecord(String inputFile, String outputFile, int audioChannel)             throws Excepti