ngswfx
0个粉丝
55
问答
1
专栏
40
资料
5895
- 收藏
- 点赞
- 分享
- 举报
微信扫码分享
QQ好友
【已解决】让设备支持rtsp 265 IPC 汉邦 海康 雄迈测试通过
本帖最后由 ngswfx 于 2016-6-23 19:57 编辑
以前的rtsp client 源码是针对264搞的，准备在调整支持265。
但不知在哪方面入手，由于用的tcp方式接收数据，是在数据包封装层面修改吗？哪位大侠给点建议。
///////////////////////目前进度，还没得到原始流，2016_6_3
我现在手上有个支持265的HB IPC，我折腾半天，连265的影子都没看见，过来的流还是264的(设备也支持264,在setup命令交互阶段，选择连接哪一个）。
仅仅在describe数据包过来的时候，多了一个rtmp=98（看网上介绍，说H265这个值，没有明确，所以估计各家自己自定义了），估计是去连接这个trackID的数据流。我尝试连接，PLAY后，可惜没有得到任何原始数据包。
/////////////////后来调通后，才发现厂家的IE ocx控件为了避免超级频繁的更新，所以和以前264版本的IPC兼容，没主动更新程序，我强制更新后，IE控制界面多了一个265编码选项。然后rtsp交互数据里面就变成了 96/H265
这几天，再着手测试一下HK的IPC，最起码先得到原始的数据包再说。
//////////////////////////2016_6_6,查看文档
[url]https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-14[/url]
最新的是RFC7798
[url]https://tools.ietf.org/html/rfc7798[/url]
/////////////////////////////2016_6_7,想想BT办法，终于过滤得到需要的流，解码265成功了。
//对比了HK文件，发现I帧0001后面跟的是：0x26 0x01 0xaf 普通帧是0x02 0x01 0xd0
代码中：
else if (type == TYPE_FU)
{
/*
TRACE("Parsing FU\n");
*/
LPFUH265 fuh = (LPFUH265)(payload+sizeof(NALUH265));
if (fuh->s)
{
m_current_ts = ts;
if (m_uNaluDataLen != 0)
{
TRACE("receiving FU start while previous FU-A is not finished\n");
}
unsigned short usNewNaluH = usNaluH;// ntohs(*(unsigned short*)payload);
LPNALUH265 newnaluh = (LPNALUH265)&usNewNaluH;
newnaluh->type = fuh->type;
usNewNaluH = htons(usNewNaluH);
AddToNaluBuf((const char*)&usNewNaluH, sizeof(usNewNaluH), TRUE); ///这里导入的数据不符合要求，都是0x62 0x01，强制修改符合要求后，解码正常，看来还需要研究这个nalu header，使其产生正确。
AddToNaluBuf(payload+3, rtpdata+rtplen-(payload+3));
}
else
{
if (m_uNaluDataLen > 0)
{
AddToNaluBuf(payload+3, rtpdata+rtplen-(payload+3));
}
else
{
TRACE("Receiving continuation FU packet but no start.\n");
Reset();
return FALSE;
}
}
///////////////////////////经过仔细测试，发现问题就出在：
LPNALUH265 newnaluh = (LPNALUH265)&usNewNaluH;
newnaluh->type = fuh->type;
////////////////////////执行后usNewNaluH并没有更新。 通过new一个全新的NALUH265，然后赋值拷贝的方式，问题得到解决
///////////////////测试汉邦 265 IPC ，通过
//////////////////测试雄迈模组265 IPC，没通过，查看printf信息，发现代码中char* payload = (char*)(rtpdata+12+h->cc*4+h->extbit*4); h->cc和h->extbit有一个不是0,是2。
//这直接导致偏移了8个字节。直接把代码改成char* payload = (char*)(rtpdata+12);通过，再次测试汉邦以及海康IPC，都可以。暂时这么用吧。
做兼容就是这样的，没有对错，没有理论，管他谁错，关键能出图。:lol
以前的rtsp client 源码是针对264搞的，准备在调整支持265。
但不知在哪方面入手，由于用的tcp方式接收数据，是在数据包封装层面修改吗？哪位大侠给点建议。
///////////////////////目前进度，还没得到原始流，2016_6_3
我现在手上有个支持265的HB IPC，我折腾半天，连265的影子都没看见，过来的流还是264的(设备也支持264,在setup命令交互阶段，选择连接哪一个）。
仅仅在describe数据包过来的时候，多了一个rtmp=98（看网上介绍，说H265这个值，没有明确，所以估计各家自己自定义了），估计是去连接这个trackID的数据流。我尝试连接，PLAY后，可惜没有得到任何原始数据包。
/////////////////后来调通后，才发现厂家的IE ocx控件为了避免超级频繁的更新，所以和以前264版本的IPC兼容，没主动更新程序，我强制更新后，IE控制界面多了一个265编码选项。然后rtsp交互数据里面就变成了 96/H265
这几天，再着手测试一下HK的IPC，最起码先得到原始的数据包再说。
//////////////////////////2016_6_6,查看文档
[url]https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-14[/url]
最新的是RFC7798
[url]https://tools.ietf.org/html/rfc7798[/url]
/////////////////////////////2016_6_7,想想BT办法，终于过滤得到需要的流，解码265成功了。
//对比了HK文件，发现I帧0001后面跟的是：0x26 0x01 0xaf 普通帧是0x02 0x01 0xd0
代码中：
else if (type == TYPE_FU)
{
/*
TRACE("Parsing FU\n");
*/
LPFUH265 fuh = (LPFUH265)(payload+sizeof(NALUH265));
if (fuh->s)
{
m_current_ts = ts;
if (m_uNaluDataLen != 0)
{
TRACE("receiving FU start while previous FU-A is not finished\n");
}
unsigned short usNewNaluH = usNaluH;// ntohs(*(unsigned short*)payload);
LPNALUH265 newnaluh = (LPNALUH265)&usNewNaluH;
newnaluh->type = fuh->type;
usNewNaluH = htons(usNewNaluH);
AddToNaluBuf((const char*)&usNewNaluH, sizeof(usNewNaluH), TRUE); ///这里导入的数据不符合要求，都是0x62 0x01，强制修改符合要求后，解码正常，看来还需要研究这个nalu header，使其产生正确。
AddToNaluBuf(payload+3, rtpdata+rtplen-(payload+3));
}
else
{
if (m_uNaluDataLen > 0)
{
AddToNaluBuf(payload+3, rtpdata+rtplen-(payload+3));
}
else
{
TRACE("Receiving continuation FU packet but no start.\n");
Reset();
return FALSE;
}
}
///////////////////////////经过仔细测试，发现问题就出在：
LPNALUH265 newnaluh = (LPNALUH265)&usNewNaluH;
newnaluh->type = fuh->type;
////////////////////////执行后usNewNaluH并没有更新。 通过new一个全新的NALUH265，然后赋值拷贝的方式，问题得到解决
///////////////////测试汉邦 265 IPC ，通过
//////////////////测试雄迈模组265 IPC，没通过，查看printf信息，发现代码中char* payload = (char*)(rtpdata+12+h->cc*4+h->extbit*4); h->cc和h->extbit有一个不是0,是2。
//这直接导致偏移了8个字节。直接把代码改成char* payload = (char*)(rtpdata+12);通过，再次测试汉邦以及海康IPC，都可以。暂时这么用吧。
做兼容就是这样的，没有对错，没有理论，管他谁错，关键能出图。:lol
我来回答
回答19个
时间排序
认可量排序
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
或将文件直接拖到这里
悬赏：
E币
网盘
* 网盘链接：
* 提取码：
悬赏：
E币
Markdown 语法
- 加粗**内容**
- 斜体*内容*
- 删除线~~内容~~
- 引用> 引用内容
- 代码`代码`
- 代码块```编程语言↵代码```
- 链接[链接标题](url)
- 无序列表- 内容
- 有序列表1. 内容
- 缩进内容
- 图片
相关问答
-
2016-04-19 23:02:09
-
2016-10-25 21:20:43
-
2016-07-04 08:47:34
-
2017-04-24 18:34:54
-
2015-07-28 14:21:13
-
2016-07-25 12:33:28
-
2016-06-01 18:15:34
-
2018-03-29 14:02:45
-
2018-05-15 10:36:07
-
2019-01-22 11:49:16
-
2014-12-08 09:42:40
-
2016-03-22 10:19:16
-
2016-05-31 09:23:01
-
2016-07-13 09:32:28
-
2017-09-17 20:42:35
-
2016-10-30 19:00:28
-
2018-01-31 12:45:55
-
2016-09-09 17:43:12
-
2016-03-22 10:21:21
无更多相似问答 去提问
点击登录
-- 积分
-- E币
提问
—
收益
—
被采纳
—
我要提问
切换马甲
上一页
下一页
举报反馈
举报类型
- 内容涉黄/赌/毒
- 内容侵权/抄袭
- 政治相关
- 涉嫌广告
- 侮辱谩骂
- 其他
详细说明
提醒
你的问题还没有最佳答案，是否结题，结题后将扣除20%的悬赏金
取消
确认
提醒
你的问题还没有最佳答案，是否结题，结题后将根据回答情况扣除相应悬赏金（1回答=1E币）
取消
确认
关注公众号
联系我们
社区问题咨询：Ebaina-CN
定制需求咨询：xxqk158820
社区问题咨询：Ebaina-CN
定制需求咨询：xxqk158820
回顶部
