查看: 12206|回复: 14
在线时间27 小时注册时间最后登录阅读权限100帖子精华0积分10UID74661
新手上路, 积分 10, 距离下一级还需 40 积分
我利用x264压缩摄像头采集的实时数据，压缩成功后想知道PPS和SPS的值，因为需要将其进行base64编码放入SDP文件中，希望各位能给指点下
在线时间926 小时注册时间最后登录阅读权限150帖子精华38积分5758UID1900
NALU 第一字节低 5 位为 7 和 8 的 NALU。
欢迎加入我们的QQ群：。新加入者请先仔细阅读论坛中的！
在线时间27 小时注册时间最后登录阅读权限100帖子精华0积分10UID74661
新手上路, 积分 10, 距离下一级还需 40 积分
多谢斑竹回答。
这个我是知道的，接受数据的时候可以通过这个方法判断NALU类型，从而取得相应的SPS,PPS .或从SDP中得到SPS,PPS 。我这边的问题是我是直接送YUV测试序列到X264压缩数据再RTP发送出去，我看了下压缩出来的帧都是标准的H264帧了，没有sps,pps的帧，我这边是要组合SDP发给服务器告诉服务器我这边的压缩参数，不是读取服务器发过来的数据帧，所以无法从压缩的帧中取得SPS,PPS，斑竹还能再知道下这种情况应该如何取得这两个值啊。
在线时间926 小时注册时间最后登录阅读权限150帖子精华38积分5758UID1900
不可能没有 SPS\PPS，否则 X264 编码出来的码流为什么可以解码呢？SPS\PPS 不是帧，只是 NALU，包含在码流数据中，你只要提取出来就可以了。你去详细了解一下 SPS\PPS 就知道了。
欢迎加入我们的QQ群：。新加入者请先仔细阅读论坛中的！
在线时间27 小时注册时间最后登录阅读权限100帖子精华0积分10UID74661
新手上路, 积分 10, 距离下一级还需 40 积分
哦，也就是SPS,PPS 只有在编码过程中才能取得，如果没有开始编码这两个值是取不到的，是吧？　
刚才重新的看了下，编码后有很多nal_type 为1 的nalu ,以及多个为 7 的 nalu,我在怀疑是不是我的编码的参数有问题。　好像ＳＰＳ的NALU并不是在最开始的，这就比较疑惑了，当数据开始压缩的时候也就是开始传输的时候，因为是实时数据，才能知道SPS，PPS ，这个时候知道的话是不是有点晚了，因为SDP的发送是在数据发送前完成的吧 。
在线时间27 小时注册时间最后登录阅读权限100帖子精华0积分10UID74661
新手上路, 积分 10, 距离下一级还需 40 积分
刚发现通过encode_header()也可以得到SPS,PPS
在线时间52 小时注册时间最后登录阅读权限100帖子精华0积分69UID75909
注册会员, 积分 69, 距离下一级还需 131 积分
问下你是用什么工具看编码后的数据（NALU）格式，谢谢
kevin@video
在线时间27 小时注册时间最后登录阅读权限100帖子精华0积分10UID74661
新手上路, 积分 10, 距离下一级还需 40 积分
在线时间52 小时注册时间最后登录阅读权限100帖子精华0积分69UID75909
注册会员, 积分 69, 距离下一级还需 131 积分
谢谢，我试试
在线时间52 小时注册时间最后登录阅读权限100帖子精华0积分69UID75909
注册会员, 积分 69, 距离下一级还需 131 积分
可能我没说明白。我利用visual C++ 6.0跑JM软件得到编码后的文件 test.264,采用了RTP数据结构。我现在想要看到这一个个的RTP，不知什么样的工具可做到？ LZ 说的那个好像是个编译软件，我想知道有没有一个方便的小软件能够满足我的要求？谢谢
在线时间926 小时注册时间最后登录阅读权限150帖子精华38积分5758UID1900
JM 的 RTP 格式不是标准格式，没有软件可以分析。
欢迎加入我们的QQ群：。新加入者请先仔细阅读论坛中的！
在线时间5 小时注册时间最后登录阅读权限100帖子精华0积分5UID79257
新手上路, 积分 5, 距离下一级还需 45 积分
kevin@video
& & 你好 加我qq啊 我和你研究方向一样
我怕忘了 你验证注明个SPS 谢谢了啊
在线时间3 小时注册时间最后登录阅读权限100帖子精华0积分2UID79954
新手上路, 积分 2, 距离下一级还需 48 积分
SDP是什么意思？？？
在线时间926 小时注册时间最后登录阅读权限150帖子精华38积分5758UID1900
google、百度
在线时间37 小时注册时间最后登录阅读权限100帖子精华0积分24UID93959
新手上路, 积分 24, 距离下一级还需 26 积分
楼主， 加我啊&&需要你的帮助 拜托了&&qq&&
Powered byH.264码流帧率，比特率，时间戳的获得
[问题点数：20分]
H.264码流帧率，比特率，时间戳的获得
[问题点数：20分]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
2011年11月 专题开发/技术/项目大版内专家分月排行榜第二2011年8月 专题开发/技术/项目大版内专家分月排行榜第二
本帖子已过去太久远了，不再提供回复功能。2565人阅读
live555（1）
关于pps 和 sps 有两种方法传给播放器
一、发送SDP方式。
参数 sprop-parameter-sets 就是 pps sps 的base64转换码，中间用&,& 隔开。
二、当有客户加入组播时发送
因为pps 和 sps相同 ，不会影响 到原来已连接上的 客户端 。
三、每个I_Frame 前加上
SDP中的H.264的SPS和PPS串，包含了初始化H.264解码器所需要的信息参数，包括编码所用的profile，level，图像的宽和高，deblock滤波器等。
由于SDP中的SPS和PPS都是BASE64编码形式的，不容易理解。例如：
sps中的内容为：
Z0LgFNoFglE=
pps中的内容为：
最终解析的到的结果为：
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
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：55449次
排名：千里之外
转载：53篇
评论：25条
(1)(1)(2)(1)(1)(4)(3)(2)(1)(4)(2)(5)(11)(21)转：rtmp 时间戳问题 - Hatim - 博客园
随笔 - 5, 文章 - 2, 评论 - 0, 引用 - 0
花了5天时间，终于解决了一个bug，心情非常愉快，憋了这么久，不吐不快。&事情是这样的，前面跟外地一家公司，开发一个二路RTSP音视频合成一路RTMP音视频的设备。设备在公司内运行是好好的，可到了现场，出现直播流畅，录制后点播卡顿的问题。由于设备在外地，调试不方便。只能这边写日志打印代码，那边烧程序调试，于是远程调试的恶梦开始了。远程操作画面卡不说，关键是慢，本来一个几分钟的事情，远程要搞几十分钟。长达5天的远程调试，真是对人的耐性的一种考验。&首先我怀疑的是时间戳不均匀。于是我将发送端的时间戳，接收端的时间戳分别日志成文件，统计，没有发现过大或过小的时间戳。也没有发现累计时间戳和累计到达时间偏差很大。这样能排除时间戳的问题。&其次我怀疑是数据格式的问题。我们这边RTSP的数据源设备和现场的不一样。于是我又写代码，将RTSP下拉的数据保存文件，去掉RTP头，添加SPS、PPS，保存为裸H264文件。数据用VLC播放这个裸H.264文件，结果可以流畅播放，说明视频数据是完整的。再写代码将H264文件分帧并用RTMP协议打包发送直播，FP能流畅直播，录制依然是卡的。开始怀疑我的分帧发送代码是否有问题，于是将我以前录制好的H.264文件拿来，用同样的方法测试，结果直播流畅，录制流畅。同样的代码不同H264文件有不同效果，那么可能是H264文件格式的不同。于是分析h264文件的NAL。NAL等于5的就是关键帧。录制流畅的h264每个关键帧之间的间隔是固定的32，而录制卡顿的H264文件，十几个关键帧连在一起。根据以往经验，这是变码率的H264数据。我的RTMP协议栈并没用支持这种格式。于是开始分析这种变码率的h264格式，在我自己的电脑里面搭建环境调试改写协议栈，轻车熟路，没过多久，我的RTMP协议栈能支持发送这种变码率的H264数据直播了。直播流畅，录制流畅。好像问题攻克了。于是带着高兴的心情，将程序更新到我的远程设备，运行。一看效果，刚开始直播和录制流畅，没过多久就开始卡顿了。和之前卡顿不同的是，卡顿频率降低了，而且FP会反复打印日志NetStream.Buffer.Empty。刚才高兴的心情一下子仿佛回到了解放前。&根据经验，这种情况一般是网络带宽不足，播放端缓存不足，或时间戳过小导致。于是我让在现场的工作的人员测试播放，结果他们在局域网看效果仍然卡顿，排除了带宽不足的问题。然后我增加播放器缓存到5秒，播放依然卡顿，又排除了缓存不足的问题。再然后我将发送端时间戳，接收端时间戳日志到文件，终于发现问题了。发送端时间戳正常，而接收端时间戳出现4000以上的大时间戳。按道理发送30帧每秒的视频，平滑处理后的时间戳应该是33-34。如果是FMS将我的时间戳修改增加了，那么会导致累计时间戳比累计时间大，但结果统计这二个值相差不大。我也没有发现有过小时间戳来中和这个大时间戳，那么累计时间戳是如何保持不变的呢，有一种可能性，丢包了。我将统计的帧数除以时间打印出来发现接收端只有20帧每秒。发送端打印的是30帧每秒。恩，可能是丢包了。我想看看是哪些数据丢了，于是将发送端的数据记录到文件，接收端接收的数据也保存到文件，对比，竟然发现数据总大小一模一样，说明没有丢包。于是我逐帧地对比发送端和接收端的数据，发现接收端有一包里面包含十多个帧的现象。而这种现象出现在接收到一个大关键帧的后面。FMS为什么会将大关键帧帧后面的小参考帧连起来做为一帧呢？这个问题我想了很久，也做了各种各样的实验。修改了多种打时间戳的方法和平滑时间戳的方法，也没有效果。最后，我猜测是否因为音频数据不足导致。因为我知道音频和视频播放不一样，它不会因为时间戳打得快就快放，它按照自己的频率计算时间匀速播放。如果音频数据不足或丢失，那么本来应该和它一起播放的视频帧会快进或跳过。于是我将发送音频部分的日志打印出来，果然发现存放问题，音频数据的环形缓存区满了，导致音频丢包。我为了防止重入，发送视频包的时候，音频不能发送。而且我们是1080P 的视频，视频关键帧有上百KB。我的音频环形缓存长度设置的10个。瞬间导致音频缓存满，然后就是音频数据丢失。于是我将音频环形缓冲长度改为30，日志显示环形缓冲最大不超过20个。小心地将最新的程序更新到设备，看效果，直播依然卡顿。我明明解决了一个BUG，竟然没有效果。神啊，救救我吧，我已经花了4天时间了，早已身心疲惫。&当然，神是不会理我的，这BUG还是要我们程序员自己解决。FP还是打印日志NetStream.Buffer.Empty。于是又来分析时间戳，统计，没有发现过大或过小的时间戳。也没有发现累计时间戳和累计到达时间偏差很大。但是发现累计时间和累计到达时间相比戳抖动比较大。说明时间戳没问题，只是有些包来晚了，然后后来又补上了。这样子好像是远程直播带宽不稳定导致。于是让在现场的工作人员测试直播，效果流畅。再让他们测测录制，也是流畅的。反复测试没出现卡顿，问题终于解决了。心情愉悦。&总结，1，找BUG需要沉下心来，找不到问题不要灰心，一定要充满斗志，否则容易中途放弃不前。 2，判断问题需要准确定位，在一个错误方向上努力完全是浪费时间。3，多做实验，写日志，用数据说话，不要凭空猜测。4，写代码的时候，日志不要多，但处理严重错误的时候还是需要日志一下，方便日后排除错误。不要像我缓冲满了也不printf一下。