易百纳 海思3516 UDP推流 WiFi 安卓端 FFMPEG解码 低延时 手把手写安卓Jni项目 ＜二＞

news/2024/11/20 1:37:00/

先说说jni层的思路, 首先拿到udp过来的裸数据, 然后简单的还原传输时的分包, 然后按照之前mediaCodec的逻辑, 一帧帧丢进解码器, 进行解码, 解码完成之后, 对surface view进行渲染.
这个流程有个前期的准备已经做好了就是我报的安卓的课程有jni音视频解码的部分, 里面花了7个小时, 讲解了如何解码, 如果同步音视频, 如何防止内存泄露, 如果没有这个课程, 我得折腾到猴年才能折腾明白, 特别是关于内存泄漏的检查部分…
Derry老师虽然课讲的不咋地, 但是让我基本入门了.

接着看看jni部分都做了啥.
首先是入口native-lib
在这里插入图片描述
startRevNative中, 新建了一个Jni层的Player, 一个用于往上层发通知的回调, 暂时没用.
见了一个UDP的接收者, 用于接收收到的UDP的数据包.

render_callback中, 用已经解码的数据对所持有的ANativeWindow进行渲染.

UDP_Receiver中
为避免阻塞, 将这个接收数据的部分用单独的线程处理

void *rev_thread(void *args) {char packetBuf[UDP_PACKET_LEN];   // udp包最大是1400int recvLen;int dataFrameLen = 0;// 强转为receiver对象指针, 为了取到sockfdauto *receiver = static_cast<UDP_Receiver *>(args);char dataFrameBuf[DATA_BUFFER_LEN];while (true) {// 读取udp数据包recvLen = read(receiver->sockfd, (char *) packetBuf, UDP_PACKET_LEN);if (recvLen < 0) {LOGD("recvfrom failed");break;}if (recvLen > 0) {// LOGD("Got data: %d bytes", recvLen);// 获取数据包的类型// 这里的注释暂时不要删除, 知道显示确定无问题frame_type_e frameType = receiver->get_frame_type(packetBuf, recvLen);// 经过分析, 只有I帧/P帧即数据帧才发送到解码器if (SPS_FRAME == frameType) {if (!receiver->ifStartRender) {LOGD("Start render");receiver->ifStartRender = true;}LOGD("SFrame insert buffered data into packet queue");// 将已经缓存的数据帧插入到队列中receiver->insert_data_into_players_packet_queue(dataFrameBuf, dataFrameLen);dataFrameLen = 0;// 加入缓存, 跟I帧一起发送memcpy(&dataFrameBuf[dataFrameLen], packetBuf, recvLen);dataFrameLen = recvLen;} else if (PPS_FRAME == frameType) {// 加入缓存, 跟I帧一起发送memcpy(&dataFrameBuf[dataFrameLen], packetBuf, recvLen);dataFrameLen = dataFrameLen + recvLen;} else if (I_FRAME == frameType) {// 加入缓存memcpy(&dataFrameBuf[dataFrameLen], packetBuf, recvLen);dataFrameLen = dataFrameLen + recvLen;} else if (D_START_PACKET == frameType) {// D帧开始了, 就把之前的先发送receiver->insert_data_into_players_packet_queue(dataFrameBuf, dataFrameLen);dataFrameLen = 0;// 加入缓存memcpy(&dataFrameBuf[dataFrameLen], packetBuf, recvLen);dataFrameLen = recvLen;} else if (D_REST_PACKET == frameType) {// 数据帧的中间部分, 直接缓存memcpy(&dataFrameBuf[dataFrameLen], packetBuf, recvLen);dataFrameLen = dataFrameLen + recvLen;}}usleep(1);}return nullptr;
}

这里先对接收的数据帧进行一个判断, 因为发送端已经将帧做成了包, 所以数据包到安卓端, 就是几种情况:

  1. SPS帧, 这个是第一个发送的.
  2. PPS帧, 这个是第二个
  3. 如果在发送端不做丢弃处理, 这里还会发送一个SEI帧, 但是解码器遇到这个帧会报错, 甚至在雷神的那个解码工具看到的也是unknow

在这里插入图片描述
在这里插入图片描述
所以我后来选择直接在发送端把这个9字节的SEI给丢了.

在这里插入图片描述

  1. 接着就遇到个天坑, 我之前用MediaCodec的逻辑就是, 有啥就传啥, 拿到啥就往mediaCodec的inputBuffer里面扔, 然后在outputBuffer那里等着, 拿到数据就 渲染, 没问题, (但是我也发现了, 如果遇到错误帧, 解码的速度会变慢. 画面卡顿)

但是在这里, 如果我把些SPS, PPS跟I帧一个个扔到ffmpeg的解码器中时, 它居然给我报错, 而且是每秒给我报3个错, 在我去掉SEI帧之后, 报2个错, 我自然而然想到可能是这SPS跟PPS的问题.

折腾了一天之后, 对比ffmpeg对h264裸流文件解码的例程, 我发现, 注意看上面的图, 传给这个avcodec_send_packet的数据尺寸是195033字节, 而我通过分析工具看到的这个I帧, 才195001+4个分隔标识符, 也就是说, 他们居然是把SPS, PPS, 跟I帧打包成一个Packet, 丢给解码器的.
在这里插入图片描述
好吧, 我也只能如法炮制了, 这样一来, 使用avcodec_send_packet发送数据到解码器的时候, 返回就不报错了.

  1. 接着我又遇到个坑, 注意看这个函数
void UDP_Receiver::insert_data_into_players_packet_queue(char *data, int dataLen) {if (this->ifStartRender) {AVPacket *packet = av_packet_alloc();// packet->data = (uint8_t *) av_malloc(dataLen);packet->data = (uint8_t *) data;// memcpy(packet->data, data, dataLen);packet->size = dataLen;packet->stream_index = 0;this->player->videoChannel->packet_decode(packet);av_packet_unref(packet);av_packet_free(&packet);packet = nullptr;}
}

之前我是用注释中的写法, 先为AVPacket申请内存, 然后用av_molloc给data指针申请内存, 然后使用memcpy, 将收到的内存复制到packet的data中, 看起来完美吧, 结果就发现, 即便接下来啥也不错, 也不解码, native的内存就会600K/秒的速度在增长…2分钟涨到了70M
在这里插入图片描述
如果在华为手机上跑, 估计要不了3分钟, 就被系统自动杀死了…

先是在后面解码, 刷新的部分寻找泄漏点, 发现即便一点点注释掉后面的内容, 依然在泄露, 后来不知道哪根筋转了过来, 发现就是这个memcpy的过程, 泄露了内存而没有回收, 那我试试直接把接收到的数据传给解码器吧, 终于…
在这里插入图片描述
40分钟内, 内存平静如水, native消耗才46.6M

  1. 数据包的解码原本是放在一个单独线程里面进行的, 但是我感觉这部分既然是同步的操作, 直接就在数据接收端进行了, 因为毕竟接收数据间隔是30ms 而解码只需要:
    在这里插入图片描述
    大约14ms, 这特么才是硬解码吧?

  2. play是一个单独线程, 所以现在一共只有两个子线程, 一个接收数据, 一个play, play的工作就是把解码后的jyuv420数据, 解码成rgba, 然后传给渲染函数, 渲染函数这里使用了一个函数指针, 函数指针我还不熟, 就不多解释了, 总之最终是在native-lib文件中的render_callback完成了渲染, 因为只有这儿有这个ANativeWindow *window 的实例.
    这个render_callback也算是个小坑吧, 因为对函数指针确实不熟.

  3. 至此, 安卓跑起来, 海思先通过wifi的网卡连到安卓的热点, 然后直接向热点的网关发送数据, 就可以看到画面了.
    在这里插入图片描述
    高速摄影机拍摄到的画面…其实是我屏幕的刷新率不够…从摄像头捕捉到画面到安卓渲染完成, 大概是150ms左右.

遗留的问题:
1 还能更快么??
2. 目前速度的瓶颈在哪? 编码端? WiFi?
3 测试一下公网中转?


http://www.ppmy.cn/news/124851.html

相关文章

首款国产8K 50P小型化广播级摄像机背后的故事

首款国产8K 50P小型化广播级摄像机背后的故事

“博冠为什么能做摄像机?” 在博冠推出8K超高清摄像机G1之时,很多声音在行业响起,一家做望远镜的公司,凭什么能做8K摄像机? 而这次,首款国产8K 50P小型化广播级摄像机投入2022冬季冰雪体育盛会开幕式使用,更是往本来就不平静的湖面扔下一个巨石。 其实,博冠从望远镜到摄像…
阅读更多...
深度摄像机精度评测

深度摄像机精度评测

深度摄像机精度评测主要从以下几个方面着手。 1&#xff0c;深度精度&#xff08;depth accuray&#xff09; 像素点对应的ground truth深度值&#xff0c;与深度相机获取到的深度均值的差&#xff0c;作为深度精度。 实际测试时&#xff0c;使用到深度摄像机中心不同距离&a…
阅读更多...
星光级摄像机

星光级摄像机

概念 星光级摄像机是指在微光情况下&#xff0c;通常指星光环境下无任何辅助光源&#xff0c;可以显示清晰的彩色图像的摄像机&#xff0c;它区别于普通摄像机只能显示黑白图像&#xff0c;在夜间能够彩色成像的摄像机能够极大的提高监控效果。 技术 星光级摄像机采用了超灵…
阅读更多...
如何使用MapStruct优雅的告别get,set

如何使用MapStruct优雅的告别get,set

我们开发过程中会遇到很多bean拷贝的过程&#xff0c;最简单粗暴得方法就是set/get方法&#xff0c;当然这也是最臃肿的方法&#xff0c;代码显得过于冗长和笨重&#xff0c;其次还有框架BeanUtils在使用反射的时候都会影响到性能。虽然我们可以进行反射信息的缓存来提高性能。…
阅读更多...
近景摄影测量

近景摄影测量

步骤&#xff1a; &#xff08;1&#xff09;求相机的内外方位元素&#xff1a;三维检校场&#xff0c;二维检校场&#xff08;单反相机变焦镜头设置为定焦模式[数码相机没有变焦一说]-->拍摄像片-->根据特征点匹配定位(二维平面检校)&#xff09; &#xff08;2&#xf…
阅读更多...
车载监控4大趋势，TSINGSEE助力车载视频监控高清、智能化发展

车载监控4大趋势，TSINGSEE助力车载视频监控高清、智能化发展

一、行业发展趋势 作为视频监控行业的重要分支&#xff0c;车载视频监控是交通监控领域的重要应用。基于车载监控&#xff0c;企业和政府监管部门可以对营运车辆的运行线路、车速、上下旅客、装卸货物等情况进行24小时不间断地监控和记录。随着互联网的高速发展&#xff0c;车…
阅读更多...
情报板/路政/枪机/卡口/监控类摄像机

情报板/路政/枪机/卡口/监控类摄像机

道路上的LED可变情报板 交警路政 在治超中交警只负责拦车&#xff0c;开处罚决定书&#xff0c;路政不得拦车&#xff0c;只负责称重检测&#xff01; 不仅治超罚款 路政还肩负道路安全责任 其实&#xff0c;路政队伍中人员素质层次不齐&#xff0c;难免出现不公现象&#x…
阅读更多...
国产8K摄像机拍摄回顾与画面数据反馈

国产8K摄像机拍摄回顾与画面数据反馈

本文分析两款国产8K摄像机&#xff0c;一款是全画幅&#xff0c;一款是M43画幅。 一、全新国产全画幅8K B1 机器参数数据汇总&#xff1a; 全画幅8K 60fps&#xff0c;受益于8K全画幅的优势与大幅升级的图像处理系统&#xff0c;BOSMA 8K摄像机系统提升到新的高度。 拍摄支持&a…
阅读更多...
最新文章

Copyright @ 2022~2023