前篇博客介绍了Android EasyRTMP App的一些功能以及简单实现.这篇博客介绍一下我们遇到的一个BUG,以及它的出现原因,解决方式.
这个bug是在切换分辨率的时候,偶尔会出现App崩溃.我们经过不断测试发现在低分辨率切换至高分辨率的时候更容易出现,后来查看日志,发现打印的日志比较奇怪,是一些Native层的崩溃,并没有任何堆栈信息展示:
--------- beginning of crash
09-21 13:39:26.636 24221 24231 F libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0xc in tid 24231 (HeapTaskDaemon)
09-21 13:39:26.744 578 578 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
09-21 13:39:26.744 578 578 F DEBUG : Build fingerprint: 'Hisense/E76mini/HS8937QC:6.0.1/MMB29M/L1304.6.01.01:user/release-keys'
09-21 13:39:26.744 578 578 F DEBUG : Revision: '0'
09-21 13:39:26.744 578 578 F DEBUG : ABI: 'arm64'
09-21 13:39:26.745 578 578 F DEBUG : pid: 24221, tid: 24231, name: HeapTaskDaemon >>> org.easydarwin.easyrtmp <<<
09-21 13:39:26.745 578 578 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xc
09-21 13:39:26.770 578 578 F DEBUG : x0 0000000000000004 x1 0000000000000000 x2 0000007f7b36bca0 x3 00000055a5c9bae0
09-21 13:39:26.770 578 578 F DEBUG : x4 0000000000000000 x5 00000000051fa000 x6 0000007f7f5e27c8 x7 4104100004104100
09-21 13:39:26.770 578 578 F DEBUG : x8 00000000002450a0 x9 0000000000001228 x10 00000055a5c9bb04 x11 0000000000000000
09-21 13:39:26.770 578 578 F DEBUG : x12 00000000000000ab x13 0000000000002ddd x14 00000055a5c9bb00 x15 00000000000000a9
09-21 13:39:26.770 578 578 F DEBUG : x16 00000055a5c9bb04 x17 0000000000000000 x18 0000000000002ddd x19 0000000000002de1
09-21 13:39:26.770 578 578 F DEBUG : x20 00000000706df038 x21 000000000000000c x22 0000007f7c2bb000 x23 0000007f7c2bf2f0
09-21 13:39:26.770 578 578 F DEBUG : x24 0000000000000000 x25 0000000079aeb000 x26 0000000000000003 x27 00000055a5c9c310
09-21 13:39:26.770 578 578 F DEBUG : x28 0000007f7b36bca0 x29 0000007f7b36bbe0 x30 0000007f7b36bca8
09-21 13:39:26.771 578 578 F DEBUG : sp 0000007f7b36bbe0 pc 0000007f7beb8e64 pstate 0000000080000000
09-21 13:39:26.787 578 578 F DEBUG :
09-21 13:39:26.787 578 578 F DEBUG : backtrace:
09-21 13:39:26.788 578 578 F DEBUG : #00 pc 000000000021fe64 /system/lib64/libart.so (_ZN3art2gc9collector9MarkSweep16ProcessMarkStackEb+220)
09-21 13:39:26.788 578 578 F DEBUG : #01 pc 0000000000220800 /system/lib64/libart.so (_ZN3art2gc9collector9MarkSweep12MarkingPhaseEv+256)
09-21 13:39:26.788 578 578 F DEBUG : #02 pc 0000000000220b58 /system/lib64/libart.so (_ZN3art2gc9collector9MarkSweep9RunPhasesEv+732)
09-21 13:39:26.788 578 578 F DEBUG : #03 pc 0000000000212cc8 /system/lib64/libart.so (_ZN3art2gc9collector16GarbageCollector3RunENS0_7GcCauseEb+296)
09-21 13:39:26.788 578 578 F DEBUG : #04 pc 000000000024506c /system/lib64/libart.so (_ZN3art2gc4Heap22CollectGarbageInternalENS0_9collector6GcTypeENS0_7GcCauseEb+2056)
09-21 13:39:26.788 578 578 F DEBUG : #05 pc 000000000024690c /system/lib64/libart.so (_ZN3art2gc4Heap16ConcurrentGCTask3RunEPNS_6ThreadE+152)
09-21 13:39:26.788 578 578 F DEBUG : #06 pc 000000000026963c /system/lib64/libart.so (_ZN3art2gc13TaskProcessor11RunAllTasksEPNS_6ThreadE+80)
09-21 13:39:26.788 578 578 F DEBUG : #07 pc 0000000001ffa57c /system/framework/arm64/boot.oat (offset 0x1ffa000)
09-21 13:39:27.169 578 578 F DEBUG :
09-21 13:39:27.169 578 578 F DEBUG : Tombstone written to: /data/tombstones/tombstone_03
这种问题一般是内存越界或者无效内存导致的.仔细一想会不会是编码器内部bug,比如说不支持切换后的这个1080P分辨率?
那我们可以先屏蔽切换的过程,直接用1080P作为初始化分辨率试下?
OK,将初始化分辨率改为1920*1080后,发现并不崩溃,那就不是因为编码器不支持了.
那再想下,切换后导致崩溃,是不是因为编码器初始化依然用的老的分辨率参数?这个也是很有可能的一个bug,因为这种异步的切换,很多先来后到的问题,这样就很难面面俱到,也就无法按照我们所期待的顺序来执行,即很可能用老的参数初始化了编码器,但是数据帧却用1080P的视频帧来喂编码器.
再检查一遍代码,发现的确是这种问题.
在切换分辨率时width和height是在主线程进行的,分辨率更改后,在初始化编码器时,还是用老的摄像头的分辨率.而后续给编码器喂视频数据时,视频帧的分辨率已经是更改过的了.这时,编码器内部就会内存溢出.
更改办法则是把切换的过程都同步进行,即:
按照这种思路,需要将图表里的这些动作都POST到摄像头线程,经过这样修改后,这个bug不会再出现了.
关于EasyRTMP推流SDK
EasyRTMP是一套调用简单、功能完善、运行高效稳定的RTMP功能组件,经过多年实战和线上运行打造,支持RTMP推送断线重连、环形缓冲、智能丢帧、网络事件回调,支持Windows、Linux、arm(hisiv100/hisiv200/hisiv300/hisiv400/etc..)、Android、iOS平台,支持市面上绝大部分的RTMP流媒体服务器,包括Red5、Ngnix_rtmp、crtmpserver等主流RTMP服务器,能够完美应用于各种行业的直播需求,手机直播、桌面直播、摄像机直播、课堂直播等等方面!
点击链接加入群【EasyRTMP-RTMP直播推送】:587254841
获取更多信息
Copyright © EasyDarwin.org 2012-2017