在使用ffmpeg解碼播放TS流的時候（例如之前寫過的UDP組播流），在連接時往往需要耗費大量時間。經過debug發現是av_find_stream_info（已拋棄，現在使用的是avformat_find_stream_info）這個方法十分耗時，而且是阻塞的。av_find_stream_info方法主要是獲得相應的流信息，其中對我的應用最有用的就是視頻的分辨率。在av_find_stream_info中是要不斷的讀取數據包，解碼獲得相應的信息，而其中除了分辨率信息以外的東西對我的應用中是無用的。所以，考慮自己手動從H.264碼流中解析出視頻的分辨率信息。
以下內容主要參考了這篇文章：http://www.myexception.cn/internet/586390.html
H.264碼流的流信息都存儲在了特殊的結構中，叫做SPS(Sequence Parameter Set)。要解析SPS就需要知道一些H.264碼流的格式信息。
在H.264碼流中，都是以0x00 0x00 0x01 或者 0x00 0x00 0x00 0x01為開始碼的（在我的應用中為后者），之后通過檢測開始碼后第一個字節的后五位是否為7（00111）來判斷其是否為SPS。得到SPS之后，就可以解析出視頻的分辨率。SPS中有兩個成員，pic_width_in_mbs_minus1和pic_height_in_map_units_minus_1，分別表示圖像的寬和高，但是要注意的是它們都是以16為單位（在面積上就是以16*16的塊為單位）再減1，所以實際的寬是(pic_width_in_mbs_minus1 + 1)*16，高為(pic_height_in_map_units_minus_1+1)*16。
歡迎轉載，轉載請注明出處：http://guoyb.com/Tech/34.html
以下是解析寬高的代碼：
轉載http://guoyb.com/Tech/34.html
以下部分 轉自 http://blog.csdn.net/pkueecser/article/details/7367641
使用RTP傳輸H264的時候,需要用到sdp協議描述,其中有兩項:Sequence Parameter Sets (SPS) 和Picture Parameter Set (PPS)需要用到,那么這兩項從哪里獲取呢?答案是從H264碼流中獲取.在H264碼流中,都是以"0x00 0x00 0x01"或者"0x00 0x00 0x00 0x01"為開始碼的,找到開始碼之后,使用開始碼之后的第一個字節的低5位判斷是否為7(sps)或者8(pps), 及data[4] & 0x1f == 7 || data[4] & 0x1f == 8.然后對獲取的nal去掉開始碼之后進行base64編碼,得到的信息就可以用於sdp.sps和pps需要用逗號分隔開來.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
如何解析SDP中包含的H.264的SPS和PPS串
http://www.pernet.tv.sixxs.org/thread-109-1-1.html
SDP中的H.264的SPS和PPS串，包含了初始化H.264解碼器所需要的信息參數，包括編碼所用的profile，level，圖像的寬和高，deblock濾波器等。
由於SDP中的SPS和PPS都是BASE64編碼形式的，不容易理解，附件有一個工具軟件可以對SDP中的SPS和PPS進行解析。
用法是在命令行中輸入：
spsparser sps.txt pps.txt output.txt
例如sps.txt中的內容為：
Z0LgFNoFglE=
pps.txt中的內容為：
aM4wpIA=
最終解析的到的結果為：
Start dumping SPS:
profile_idc = 66
constrained_set0_flag = 1
constrained_set1_flag = 1
constrained_set2_flag = 1
constrained_set3_flag = 0
level_idc = 20
seq_parameter_set_id = 0
chroma_format_idc = 1
bit_depth_luma_minus8 = 0
bit_depth_chroma_minus8 = 0
seq_scaling_matrix_present_flag = 0
log2_max_frame_num_minus4 = 0
pic_order_cnt_type = 2
log2_max_pic_order_cnt_lsb_minus4 = 0
delta_pic_order_always_zero_flag = 0
offset_for_non_ref_pic = 0
offset_for_top_to_bottom_field = 0
num_ref_frames_in_pic_order_cnt_cycle = 0
num_ref_frames = 1
gaps_in_frame_num_value_allowed_flag = 0
pic_width_in_mbs_minus1 = 21
pic_height_in_mbs_minus1 = 17
frame_mbs_only_flag = 1
mb_adaptive_frame_field_flag = 0
direct_8x8_interence_flag = 0
frame_cropping_flag = 0
frame_cropping_rect_left_offset = 0
frame_cropping_rect_right_offset = 0
frame_cropping_rect_top_offset = 0
frame_cropping_rect_bottom_offset = 0
vui_parameters_present_flag = 0
Start dumping PPS:
pic_parameter_set_id = 0
seq_parameter_set_id = 0
entropy_coding_mode_flag = 0
pic_order_present_flag = 0
num_slice_groups_minus1 = 0
slice_group_map_type = 0
num_ref_idx_l0_active_minus1 = 0
num_ref_idx_l1_active_minus1 = 0
weighted_pref_flag = 0
weighted_bipred_idc = 0
pic_init_qp_minus26 = 0
pic_init_qs_minus26 = 0
chroma_qp_index_offset = 10
deblocking_filter_control_present_flag = 1
constrained_intra_pred_flag = 0
redundant_pic_cnt_present_flag = 0
transform_8x8_mode_flag = 0
pic_scaling_matrix_present_flag = 0
second_chroma_qp_index_offset = 10
/////////////////////////////////////////////////////////////////////////////////////////////////
這里需要特別提一下這兩個參數
pic_width_in_mbs_minus1 = 21
pic_height_in_mbs_minus1 = 17
分別表示圖像的寬和高，以宏塊（16x16）為單位的值減1
因此，實際的寬為 (21+1)*16 = 352
spsparser.rar
http://krdai.info.sixxs.org/blog/mp4-sps-pps-data.html
最近在做跟 h264 encode/decode 相關的研究，目標是希望可以從 Android 的 MediaRecorder 當中取出 h264 的資訊。目前問題是在於 SPS 以及 PPS 到底要怎樣得到。由於 MediaRecorder 是寫入 mp4 檔案中，所以不得已只好來去分析一下 mp4 的檔案格式，發現沒有想像中的困難. 主要是參照 ISO/IEC 14496-15 這部份. 在 mp4 的檔案之中, 找到 avcC 這個字串, 之後就是接上 AVCDecoderConfigurationRecord. AVCDecoderConfigurationRecord 的 format 如下:
- aligned(8) class AVCDecoderConfigurationRecord {
- unsigned int(8) configurationVersion = 1;
- unsigned int(8) AVCProfileIndication;
- unsigned int(8) profile_compatibility;
- unsigned int(8) AVCLevelIndication;
- bit(6) reserved = '111111'b;
- unsigned int(2) lengthSizeMinusOne;
- bit(3) reserved = '111'b;
- unsigned int(5) numOfSequenceParameterSets;
- for (i=0; i< numOfSequenceParameterSets; i++) {
- unsigned int(16) sequenceParameterSetLength ;
- bit(8*sequenceParameterSetLength) sequenceParameterSetNALUnit;
- }
- unsigned int(8) numOfPictureParameterSets;
- for (i=0; i< numOfPictureParameterSets; i++) {
- unsigned int(16) pictureParameterSetLength;
- bit(8*pictureParameterSetLength) pictureParameterSetNALUnit;
- }
- }
對照一下這樣就可以找到 SPS 和 PPS
|
問題 packetizer_h264 packetizer warning: waiting for SPS/PPS
是因為解碼器只是在第一次執行編碼的時候，才編碼出 SPS、PPS、和I_Frame； h264 packetizer has set so, that it sends sps/pps only first keyframe, I'm trying to figure what breaks if that is changed so sps/pps is written in every keyframe. [出自| http://trac.videolan.org/vlc/ticket/1384] 解決辦法： 1、編碼器編碼出每個關鍵幀都加上SPS、PPS ，據說通常情況編碼器編出的 SPS、PPS是一樣的，所以這種方法耗費資源。 2、在服務器接收到客戶端請求時，發送第一個package 加上 SPS、PPS。 具體如下：
[http://topic.csdn.net/u/20100801/17/ef35e664-92ff-4144-a35f-3984dcf11da3.html| 參考] ======================================================================== sdp 關於pps和sps的疑問： packetization-mode 主要是定義包的模式，單一 NALU單元模式（0）；非交錯(non-interleaved)封包模式（1）；交錯(interleaved)封包模式（2） sprop-parameter-sets 等於H.264 的序列參數集和圖像參數 NAL單元，base64轉換；（即＝ sps+pps） profile-level-id 這個參數用於指示 H.264 流的 profile 類型和級別。這知道這個是啥東東 參考 黑暗長老 www.cppblog.com/czanyou/ ffmpeg decode 關於pps sps問題： stackoverflow.com/questions/3493742/problem-to-decode-h264-video-over-rtp-with-ffmpeg-libavcodec/3500432#3500432 |
如何用C語言取出H.264ES文件里的nal(sps,pps)信息。比如width, height, profile等等
請高手指點指點。。。 http://www.oschina.net/question/225813_35707
解析sps,pps的代碼在ffmpeg里面就有, 抄出來就行了, 我以前也自己寫過...
ffmpeg的libavcodec/h264_parser.c,
h264_ps.c
函數
ff_h264_decode_seq_parameter_set
ff_h264_decode_picture_parameter_set
自己可以看代碼.
H264參數語法文檔： SPS、PPS、IDR http://blog.csdn.net/heanyu/article/details/6205390
H.264碼流第一個 NALU 是 SPS（序列參數集Sequence Parameter Set）
對應H264標准文檔 7.3.2.1 序列參數集的語法進行解析