[H264編解碼引數] SPS
#前言
RTP完整流程 已經 解釋了協議 所以要涉及具體的log分析
分為：
SPS \ PPS\I幀\非I幀\FU-A
SPS 序列引數集合
SPS 屬於 [RTP header] + 單一NAL單元模式 ,所以RTP包結構如下
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|NRI| type | | +-+-+-+-+-+-+-+-+ | | | | Bytes 2..n of a Single NAL unit | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
先看 抓到的 dump
0000 80 60 e2 1d ff 6d 85 0f c6 0a 3f ef 67 64 00 29 .`â.ÿm..Æ.?ïgd.)
0010 ac 52 0a 01 40 16 ec 04 40 00 00 fa 40 00 2e e0 ¬[email protected]ì[email protected]ú@..à
0020 23 c6 0c 62 a0 #Æ.b
在上面12個byte是 [RTP Header] 對應的碼流
80 60 e2 1d ff 6d 85 0f c6 0a 3f ef ====>轉化 二進位制 1000 0000 0110 0000 1110 0010 0001 1101 v=2 p=0 x=0 CC=0 M=0 PT=96 SN=57885 1111 1111 0110 1101 1000 0101 0000 1111 timestamp 1100 0110 0000 1010 0011 1111 1110 1111 ssrc
對應wireshark 解析
Real-Time Transport Protocol 10.. .... = Version: RFC 1889 Version (2) ..0. .... = Padding: False ...0 .... = Extension: False .... 0000 = Contributing source identifiers count: 0 0... .... = Marker: False Payload type: DynamicRTP-Type-96 (96) Sequence number: 57885 Timestamp: 4285367567 Synchronization Source identifier: 0xc60a3fef (3322560495)
根據單一NAL單元模式 判斷 前1byte 是[NALU Header]
0000 67 64 00 29 ac 52 0a 01 40 16 ec 04 40 00 00 fa gd.)¬[email protected]ì[email protected]ú
0010 40 00 2e e0 23 c6 0c 62 a0 @..à#Æ.b
===> 轉化 前一個位元組
0110 0111 F=0 NRI=11 特別重要 type=7 說明是sps
wireshark 解析
H.264
NAL unit header or first byte of the payload
0... .... = F bit: No bit errors or other syntax violations
.11. .... = Nal_ref_idc (NRI): 3
...0 0111 = Type: NAL unit - Sequence parameter set (7)
剩下的就看下H264 NAL Unit Payload NALU的負載
NALU payload
64 00 29 ac 52 0a 01 40 16 ec 04 40 00 00 fa
40 00 2e e0 23 c6 0c 62 a0
從下面的 解析就知道意義
H264 NAL Unit Payload
0110 0100 = Profile_idc: High profile (100)
0... .... = Constraint_set0_flag: 0
.0.. .... = Constraint_set1_flag: 0
..0. .... = Constraint_set2_flag: 0
...0 .... = Constraint_set3_flag: 0
.... 0... = Constraint_set4_flag: 0
.... .0.. = Constraint_set5_flag: 0
.... ..00 = Reserved_zero_2bits: 0
0010 1001 = Level_id: 41 [Level 4.1 50 Mb/s]
1... .... = seq_parameter_set_id: 0
.010 .... = chroma_format_id: 1
.... 1... = bit_depth_luma_minus8: 0
.... .1.. = bit_depth_chroma_minus8: 0
.... ..0. = qpprime_y_zero_transform_bypass_flag: 0
.... ...0 = seq_scaling_matrix_present_flag: 0
010. .... = log2_max_frame_num_minus4: 1
...1 .... = pic_order_cnt_type: 0
.... 0010 0... .... = log2_max_pic_order_cnt_lsb_minus4: 3
.000 1010 = num_ref_frames: 9
0... .... = gaps_in_frame_num_value_allowed_flag: 0
.000 0001 0100 00.. = pic_width_in_mbs_minus1: 79
.... ..00 0001 0110 1... .... = pic_height_in_map_units_minus1: 44
.1.. .... = frame_mbs_only_flag: 1
..1. .... = direct_8x8_inference_flag: 1
...0 .... = frame_cropping_flag: 0
.... 1... = vui_parameters_present_flag: 1
.... .1.. = aspect_ratio_info_present_flag: 1
.... ..00 0000 01.. = aspect_ratio_idc: 1
.... ..0. = overscan_info_present_flag: 0
.... ...0 = video_signal_type_present_flag: 0
0... .... = chroma_loc_info_present_flag: 0
.1.. .... = timing_info_present_flag: 1
..00 0000 0000 0000 0000 0000 1111 1010 01.. .... = num_units_in_tick: 1001
..00 0000 0000 0000 0010 1110 1110 0000 00.. .... = time_scale: 48000
..1. .... = fixed_frame_rate_flag: 1
...0 .... = nal_hrd_parameters_present_flag: 0
.... 0... = vcl_hrd_parameters_present_flag: 0
.... .0.. = pic_struct_present_flag: 0
.... ..1. = bitstream_restriction_flag: 1
.... ...1 = motion_vectors_over_pic_boundaries_flag: 1
1... .... = max_bytes_per_pic_denom: 0
.1.. .... = max_bits_per_mb_denom: 0
..00 0110 0... .... = max_mv_length_horizontal: 11
.000 1100 = log2_max_mv_length_vertical: 11
011. .... = num_reorder_frames: 2
...0 0010 10.. .... = max_dec_frame_buffering: 9
..1. .... = rbsp_stop_bit: 1
...0 0000 = rbsp_trailing_bits: 0
Profile_idc : 指明 所用的profile 佔用8bit
Constraint_set0_flag:
Constraint_set1_flag
Constraint_set2_flag
Constraint_set3_flag
Constraint_set4_flag
Constraint_set5_flag
為0 表示不用遵循 附錄 A.2的相關條件 應該是協議文件中附錄
Reserved_zero_2bits :必須是0
Level_id:指明 level
seq_parameter_set_id:指明本序列引數集的 id 號,這個 id 號將被 picture 引數集引用 ,[0~31]
chroma_format_id:色度取樣結構
bit_depth_luma_minus8:指定了亮度矩陣的位元深度以及亮度量化引數範圍偏移量；此處取0，表示每個亮度畫素用8為表示，QpBdOffset引數為0
bit_depth_chroma_minus8:和bit_depth_luma_minus8 類似 只不過是針對色度的
qpprime_y_zero_transform_bypass_flag:
seq_scaling_matrix_present_flag:
log2_max_frame_num_minus4: 主要為了獲取 frame_num 服務的,frame_num 標識所屬影象的解碼順序
,fram-num的解碼函式是 ue(v),函式中的 v 在這裡指定:
v = log2_max_frame_num_minus4 + 4
也指明瞭 frame_num 的所能達到的最大值:
MaxFrameNum = 2( log2_max_frame_num_minus4 + 4 )
變數 MaxFrameNum 表示 frame_num 的最大值,在解碼過程中它也是一個非常重要的變數。
frame_num 是迴圈計數的,即當它到達 MaxFrameNum 後又從 0 重新開始新一輪
的計數。解碼器必須要有機制檢測這種迴圈,不然會引起類似千年蟲的問題,在影象的順序上造成
混亂。
pic_order_cnt_type:指明瞭 poc (picture order count) 的編碼方法,poc 標識影象的播放順序。
由於H.264 使用了 B 幀預測,使得影象的解碼順序並不一定等於播放順序,但它們之間存在一定的對映
關係。poc 可以由 frame-num 通過對映關係計算得來
H.264 中一共定義了三種 poc 的編碼方法,這個句法元素就是用來通知解碼器該用哪種方法來計算poc
log2_max_pic_order_cnt_lsb_minus4:指明瞭變數 MaxPicOrderCntLsb 的值:
MaxPicOrderCntLsb = 2( log2_max_pic_order_cnt_lsb_minus4 + 4 )
該變數在 pic_order_cnt_type = 0 時使用。
num_ref_frames:指定參考幀佇列可能達到的最大長度,解碼器依照這個句法元素的值開闢儲存區,
這個儲存區用於存放已解碼的參考幀, H.264 規定最多可用 16 個參考幀,本句法元素的值最大為 16
gaps_in_frame_num_value_allowed_flag:這個句法元素等於 1 時,表示允許句法元素 frame_num 可
以不連續。當傳輸通道堵塞嚴重時,編碼器來不及將編碼後的影象全部發出,這時允許丟棄若干幀
影象
pic_width_in_mbs_minus1:本句法元素加 1 後指明影象寬度,以巨集塊為單位:
PicWidthInMbs = pic_width_in_mbs_minus1 + 1
通過這個句法元素解碼器可以計算得到亮度分量以畫素為單位的影象寬度:
PicWidthInSamplesL = PicWidthInMbs * 16
從而也可以得到色度分量以畫素為單位的影象寬度:
PicWidthInSamplesC = PicWidthInMbs * 8
以上變數 PicWidthInSamplesL、PicWidthInSamplesC 分別表示影象的亮度、色度分量以畫素為單位
的寬
pic_height_in_map_units_minus1:本句法元素加 1 後指明影象高度:
PicHeightInMapUnits = pic_height_in_map_units_minus1 + 1
PicSizeInMapUnits = PicWidthInMbs * PicHeightInMapUnits
影象的高度的計算要比寬度的計算複雜,因為一個影象可以是幀也可以是場,從這個句法元素可以
在幀模式和場模式下分別計算出出亮度、色度的高。值得注意的是,這裡以 map_unit 為單位
frame_mbs_only_flag: 等於 0 時表示本序列中所有影象的編碼模式都是幀,沒有其他編
碼模式存在;等於 1 時 ,表示本序列中影象的編碼模式可能是幀,也可能是場或幀場自適應
某個影象具體是哪一種要由其他元素決定
結合 map_unit 的含義,這裡給出上一個句法元素 pic_height_in_map_units_minus1 的進一步解析步驟:
當 frame_mbs_only_flag 等於1,pic_height_in_map_units_minus1 指的是一個 picture 中幀的高度;當
frame_mbs_only_flag 等於0,pic_heght_in_map_units_minus1 指的是一個 picture 中場的高度,所以
可以得到如下以巨集塊為單位的影象高度:
FrameHeightInMbs = ( 2 – frame_mbs_only_flag ) * PicHeightInMapUnits
PictureHeightInMbs= ( 2 – frame_mbs_only_flag ) * PicHeightInMapUnits
direct_8x8_inference_flag: 用於指明 B 片的直接和 skip 模式下運動向量的預測方法
frame_cropping_flag: 用於指明解碼器是否要將影象裁剪後輸出,如果是的話,後面緊跟著的
四個句法元素分別指出左右、上下裁剪的寬度。
分別是frame_crop_left_offset,frame_crop_right_offset
,frame_crop_bottom_offset,frame_crop_bottom_offset
vui_parameters_present_flag: 指明 vui 子結構是否出現在碼流中 用以表徵視訊格式等額外資訊
aspect_ratio_info_present_flag:
aspect_ratio_idc:
overscan_info_present_flag:
video_signal_type_present_flag:
chroma_loc_info_present_flag:
timing_info_present_flag:
num_units_in_tick:
time_scale: 48000
fixed_frame_rate_flag:
nal_hrd_parameters_present_flag:
vcl_hrd_parameters_present_flag:
pic_struct_present_flag:
bitstream_restriction_flag:
motion_vectors_over_pic_boundaries_flag: 1
max_bytes_per_pic_denom:
max_bits_per_mb_denom:
max_mv_length_horizontal:
log2_max_mv_length_vertical:
num_reorder_frames:
max_dec_frame_buffering:
rbsp_stop_bit:
rbsp_trailing_bits:
解碼的元素好多? 標記
相關推薦
[H264編解碼引數] SPS
#前言 RTP完整流程 已經 解釋了協議 所以要涉及具體的log分析 分為： SPS \ PPS\I幀\非I幀\FU-A SPS 序列引數集合 SPS 屬於 [RTP header] + 單一NAL單元模式 ,所以RTP包結構如下 0
[H264編解碼引數] SEI
SEI 補充增強資訊單元 : SEI 屬於 [RTP header] + 單一NAL單元模式 ,所以RTP包結構如下 0 1 2 3 0 1 2 3
H264 編解碼協議詳解
1.、什麼是 H264？ H264 是 MPEG-4 標準所定義的最新編碼格式，同時也是技術含量最高、代表最新技術水平的視訊編碼格式之一，標準寫法應該是H.264 H264 視訊格式是經過有失真壓縮的，但在技術上儘可能做的降低儲存體積下獲得較好影象質量和低頻寬影象快速傳輸。
WEBRTC 支援H264編解碼
WEBRTC視訊編解碼支援H264 VP8 VP9 但是預設是VP8 ，根據SDP描述協商 WEBRTC H264編碼採用OPENH264 解碼採用FFMPEG 一 讓WEBRTC支援H264編碼 1. 修改配置支援H264編碼 webrtc/build/commo
關於視訊H264編解碼的應用實現
專案要用到視訊編解碼，最近半個月都在搞，說實話真是走了很多彎路，浪費了很多時間。將自己的最終成果記錄於此，期望會給其他人提供些許幫助。 參考教程： 整體過程流程如下： 顯而易見，整個過程分為三個部分：採集、
讓WebRTC支援H264編解碼
https://blog.csdn.net/foruok/article/details/69525039 最近實驗了下如何讓WebRTC支援H264編碼，記錄下，供有需要的人蔘考。 說明一下，我是在 Ubuntu Server 14.04 下編譯的 WebRTC ，使用 native（C+
x264 ffmpeg編解碼引數筆記
X264 ffmpeg 1、位元速率： 碼流（Data Rate），是指視訊檔案在單位時間內使用的資料流量 三種可選的位元速率控制方法(bitrate, CQP，CRF), 選擇的順序是 bitrate > QP > CRF QP是固定量化引
【H.264/AVC視訊編解碼技術詳解】 九、序列引數集Sequence Paramater Set(SPS)解析
《H.264/AVC視訊編解碼技術詳解》視訊教程已經在“CSDN學院”上線，視訊中詳述了H.264的背景、標準協議和實現，並通過一個實戰工程的形式對H.264的標準進行解析和實現，歡迎觀看！ “紙上得來終覺淺，絕知此事要躬行”，只有自己按照標準文件以程式碼
【視頻編解碼·學習筆記】11. 提取SPS信息程序
上一個 img http config efi 技術分享 小寫 strong 類型 一、準備工作： 回到之前SimpleH264Analyzer程序，找到SPS信息，並對其做解析 調整項目目錄結構： 修改Global.h文件中代碼，添加新數據類型UINT16，之前編寫的工
H264/AVC 視訊編解碼一些基本知識
本篇對學習H264常見的知識點做個備註。 1.H264編碼位元速率設定 對視訊進行編碼時，位元速率和視訊質量是一對矛盾的話題。一般位元速率越大，視訊丟棄冗餘資訊就越少，視訊質量就越高。但是位元速率達到一定程度，視訊質量人類無法識別，所以每種解析度都有一個閾值，編碼時按照閾值即可。一
h264視訊編解碼
KevinLib開發類庫說明本類庫為快速發視訊系統必備參考之一，實現介面簡單，開放原始碼，可以無限制的重複使用 開發工具 VC++7.0 實現了視訊採集，音訊採集，壓縮解壓編碼：H264,MPEG4,WMV9,DIVX,XVID等 另外類庫裡有一些檔案操作類，介面十分簡單，十分鐘就可以建
【VP9】libvpx在Windows和Linux平臺下的編譯和vp9編解碼器的命令列引數
=================================================================== 參考：https://www.cnblogs.com/endv/p/6866947.html &
spring mvc自定義過濾器filter實現對請求引數編解碼的程式碼
百度，google了半天即使再萬能的stackoverflow上也沒有得到解答，今天偶然間發現springmvc註解@RequestParam不是通過HttpServletRequest.java的getParameter(String name)方法得到的引數值，而
H.264（H264）解碼SPS獲取解析度和幀率
#include <stdio.h> #include <stdint.h> #include <string.h> #include <math.h> typedef unsigned int UINT; typedef
H264視訊傳輸、編解碼----RTSP協議
RTSP(Real Time Streaming Protocol), 實時流傳輸協議, 它是TCP/IP協議體系中的一個應用層協議 它是對流媒體進行控制 的網路控制協議，可以對流媒體提供諸如播放、暫停、快進、停止等操作，它負責定義具體的控制訊息、操作方法
JS中URL引數的編解碼
HTML中的$("form").serialize()函式，在submit按鈕點選時，將form表單中含有name的input整理成一個“name=aaa&pass=bbb”這樣的字串，使用g
各種音視訊編解碼學習詳解 h264 ，mpeg4 ，aac 等所有音視訊格式
媒體業務是網路的主要業務之間。尤其移動網際網路業務的興起，在運營商和應用開發商中，媒體業務份量極重，其中媒體的編解碼服務涉及需求分析、應用開發、釋放license收費等等。最近因為專案的關係，需要理清媒體的codec，比較搞的是，在豆丁網上看運營商的規範 標準，同一運營商同樣的業務在不同文件中不同的要
各種音視訊編解碼學習——————詳解 h264 ，mpeg4 ，aac 等所有音視訊格式
媒體業務是網路的主要業務之間。尤其移動網際網路業務的興起，在運營商和應用開發商中，媒體業務份量極重，其中媒體的編解碼服務涉及需求分析、應用開發、釋放license收費等等。最近因為專案的關係，需要理清媒體的codec，比較搞的是，在豆丁網上看運營商的規範 標準，同一運
IP通信中音頻編解碼技術與抗丟包技術概要
自適應 b+ 極致 較高的 嵌入式 根據 電子 dshow 部分 此文較長，建議收藏起來看。 一、一個典型的IP通信模型 二、Server2Server技術分類 Server2Server這塊也是一個專門的領域，這裏只簡單分個類。 1、同一國家相同運營商之間：
HDBn編解碼原理 n階高密度雙極性碼
規則 如果 span 不變 自己 這就是 color 密度 一個 /*------------------------------------------------------------------ HDB3 編碼解碼原理 // 轉載 ----------