mosaic调用终端接口及不同盒子问题总结

1、Mosaic调用终端接口及不同盒子问题总结文档更新记录日期版本更新内容更新人2011.11.16V0.0.1Porting接口及各盒子问题解决方案陈日强中间件调用porting接口（马赛克部分）1、配置USE_VIDEO_MOSAIC_OUTPUT_TYPE=VIDEO_MOSAIC_TS 时，拼接后的数据送往底层时调用的接口INT32_Tipanel_porting_demux_ioctl(IPANEL_DEMUX_IOCTL_eop,VOID*arg)op值为IPANEL_DEMUX_PUSH_STREAM2、配置USE_VIDEO_MOSAIC_OUTPUT_TYPE=VIDEO_MOS

2、AIC_PES或VIDEO_MOSAIC_ES时，拼接后的数据送往底层时调用的接口INT32_Tipanel_porting_vdec_ioctl(UINT32_Tdecoder,IPANEL_VDEC_IOCTL_eop,VOID*arg) op值为IPANEL_VDEC_PUSH_STREAM3、推送音频数据的接口INT32_Tipanel_porting_adec_ioctl(UINT32_Tdecoder,IPANEL_ADEC_IOCTL_eop,VOID*arg)op值为IPANEL_ADEC_PUSH_STREAM4、配置USE_MOSAIC_NEW_POSITION时，中间件调

3、用这个接口实现视频偏移INT32_T ipanel_porting_display_ioctl(UINT32_T display, IPANEL_DIS_IOCTL_e op, VOID *arg)op值为IPANEL_DIS_SET_WIN_LOCATIONST7162播放马赛克问题卡及解决方案解决播放马赛克卡方案：1、前端OCG只用1个马赛克视频，配置2M的带宽下播，终端接收1个视频时，可以看到视频有回溯的现象，说明不是带宽不够导致卡的2、录制拼接前和拼接后的码流及中间件推到porting的流和porting送解码器的流，分别分析这四个流，发现这四个流的数据都是好的3、通过分析码流发现问题

4、出现在porting，数浪的工程师也大致找出了问题的原因，并对porting做如下修改：由原来的memcpy方式改为DMA方式和中间件送给porting时的拷贝过程改为DMA，通过这种方法可以提高速度，减轻CPU的负担ST的盒子在送数据到demux前cc_control会做校验，它会把校验有错的数据丢掉，然后再送到demux上，这样会造成一部分数据丢失。现在把送数据到demux做校验去掉，解决了马赛克播放回溯问题了，播放卡的问题基本解决了4、以上问题都用文件方式（前端播放16个视频，配30M带宽）和UDP方式（前端播放16，32，48，59个视频，带宽分别用12M,16M,24M,32M）测试

5、过了，发现效果跟Hi311E的效果差不多。ST7162播放马赛克问题卡及解决方案不过，现在在公司的测试还存在一些问题：1、ST7162盒子播放马赛克2，3分钟的时候会有一点卡，不过hi3110e的平台也存在同样的问题2、ST7162盒子在退出正在播放的马赛克页面后，重新进入马赛克播放页面时有问题：有时进不去，返回4408错误；有时可以进入播放页面，但播放不了马赛克BCM7405平台播放马赛克问题1、马赛克除了44可以播放外，其它规格都不能播放原因：由于应用页面设置视频长宽和程序中数据不一致，目前程序里面是写死小视频拉伸后的大小解决方法：将程序里面的每个规格的小视频拉伸后的参数跟应用设置的参数对

6、应起来2、BCM97405的demux是软件实现的 ，DEMUX CALLBACK有问题，造成demux效率不高，从而影响到马赛克正常工作。由于出现这个问题而没人解决，所以现在不在这个平台上测试马赛克了，改为其它高清的平台。至于这个平台上的一些关于马赛克的BUG也不必要处理了，现在已经关闭。HI3716M平台播放马赛克问题1、HI3716M平台mpeg2和h.264方式都播放不出视频 原因：hi3716m平台的porting支持pes流，之前未设置。 mosaic部分，之前只是对ts流方式进行了处理，未处理pes流播发的方式。解决方法：1、修改hi3716m底层和中间件宏配置由原先的TS流处理

7、改为PES，并且mosaic代码中增加pes流功能代码，解决了mpeg2播放不出的问题2、按上面方法修改，理论上是应该可以播放h.264的马赛克，现在播放不出，可能是其它原因导致。查找其它原因发现播发的h264格式的音频未配置好，所以一直没能播出。经过重新配置前端播发的h264格式mosaic的音频，现在已经能够正常播出。2、退出正在播放的MPEG-2或H.264马赛克页面时，CPU占用率达98%以上 原因：信号量控制的代码被替换掉了，其中一个线程的while循环一直在空跑。解决方法：换成以前的老库测试发现没这个问题，然后对比代码中的不同，找到原因出在拼接前后的缓冲区处理线程中的处理逻辑不一样

8、，恢复以前的信号量的控制方式就解决了这个问题HI3716M平台播放马赛克问题3、马赛克显示压缩变形且位置不居中原因：porting对mosaic显示接口不完善解决方法：修改porting部分对mosaic显示的接口代码，修改ui中的显示代码。 HI3110E平台播放马赛克问题1、前端组播UDP马赛克地址，终端接收UDP数据播放不了原因：通过udp方式创建小窗口管理器时，无法正常获取窗口句柄解决方法：通过单步调试方法找出问题原因，代码中实现udp和cable方式，小窗口创建的方法是相同的，只要将udp的创建代码和cable方式保持相同即可2、前端播发一个卡拉ok的视频流，终端播放效果卡原因：前端

9、转码GOP参数配置错误解决方法：更改前端转码GOP参数配置，使卡拉OK的视频流转码的GOP参数跟其它视频流的GOP参数保持一样3、进入一个前端没有下播友码流的马赛克页面，再进入有下播码流的4x4页面就播放不了了 页面在销毁mosaic的时候会调用中间件销毁窗口的接口。但是，由于判断条件设置错误导致代码没有执行销毁操作而直接返回。修改dvb中销毁窗口的判断条件将 if (!me | !me-mosaicHandle) return -1; 改为 if (!me ) return -1; HI3110E平台播放马赛克问题4、播放1x1视频有点卡，画面出现马赛克，声音有时也会卡顿一下 原因：网络环境

10、的影响，es复用为ts时，数据选择的设置 解决方法：通过不断地录制码流分析出错的模块代码，分析具体的相关代码逻辑。在网络环境较好的时候测试，修改了es复用为ts时，由于码流中有些帧数据量比较大，数据处理的速度较慢时延时等待，这样解决播放卡的问题5、播放4*4马赛克视频时，终端接收少于16个视频显示不出 原因：由于在向拼接模块推送ts类型的mosaic流时，没有将时间值一同送下，导致缓冲区溢出解决方法：重新放开记录时间信息的代码，将时间值送到拼接模块HI3110E平台播放马赛克问题6、退出马赛克页面后死机原因：mosaic窗口创建和释放时，申请空间和释放空间的地址不一致。 解决方法：通过在退出m

11、osaic页面，销毁窗口的地方添加打印信息可以发现：每次都是在销毁了第一个窗口，开始销毁第二个窗口的时候死机。运行到 me-mosaic_free(player-URLsi); 这里时死机。将mosaic部分申请空间和释放空间的代码统一为sdk的调用后，问题解决了。7、播放6x6,7x7一段时间后，画面卡住不动，过一会又好了 原因：拼接模块拼接处理问题解决方法：修改拼接模块拼接代码HI3110E平台播放马赛克问题8、播放3x3,5x5,6x6,7x7马赛克，视频出不来，但有时会出现声音 原因：拼接模块mosaic背景设置问题导致的解决方法：修改背景设置9、开始播放马赛克时正常，翻到下一页时播放

12、马赛克就会卡了原因：网络原因，es复用为ts时，对数据空间不足的处理有问题解决方法：优化服务器，修改es复用为ts时，对数据空间不足时的处理方法 10、长时间播放5x5,6x6,7x7去B帧的马赛克，会有一两秒卡顿 可能是网络原因导致，因为有段时间测试不卡11、播放4x4马赛克，音视频不同步 音视频不同步确定是受到是网络的影响导致的，当不同步时过段时间会自动恢复到同步状态。问题不解决HI3110E平台播放马赛克问题12、同频点同时播发视频马赛克和场景马赛克时，视频马赛克不能正常播放原因：页面配置问题。 视频mosaic和场景mosaic配置时的ait的pid和tag值相同，导致冲突解决方法：不

13、同频点不同配置对比，发现问题出现在前端OCG配置上。修改播放马赛克的AOC配置，修改ait的pid和tag值为不同值就可以了。13、数视导航（视频马赛克）应用中小视频伴音正常，小视频图像间歇性停顿、局部花屏（马赛克）。原因：与前端播放的码流有关。当马赛克应用路径同时有UDP和文件方式，就会出现这种情况解决方法：经多次试验，逐层排查，发现与OCG服务器有关：当OCG播发的Mosaic应用中小视频的路径同时有UDP和File时，会有小视频图像停顿现象；而如果OCG播发的Mosaic应用中小视频的路径全为UDP或File时，则不会出现小视频图像停顿现象。 HI3110E平台播放马赛克问题14、播放马

14、赛克视频，所有的小视频均会出现卡和马赛克的现象原因：打印太多，且代码中es复用为ts时，ts包的编号未设置好解决方法：录流分析，录制拼接前与拼接后的码流发现，拼接前的码流是好的，拼接模块录制的es码流也是好的，但拼接后复用成ts码流是有问题。修改有问题代码，重新设置es复用为ts时的编号方式，去掉打印，测试OK15、Release分支编译的库视频马赛克中的小视频在播放时，会出现马赛克的现象原因：porting 的demux模块存在问题：1、开辟了内存没有看到释放; 2、pushstream 时没有对遗留包做处理。 解决方法：查看前端配置，项目配置，盒子CPU占用率，调高马赛克进程优先级，与老库

15、对比，新库+旧porting， 旧库+新porting等方法查找马赛克卡的原因，发现用旧的porting播放不卡，然后对比新旧porting代码的不同，新的porting有如下问题：HI3110E平台播放马赛克问题1、 在init时，旧的demux创建了三个demux,一个用来过滤psi信息，一个用来过滤音视频数据，一个预留。新的只创建了一个。2 、在新的demux的409行，ipanel_porting_demux_destroy_channel中，如果channel的type为 IPANEL_DMX_VIDEO_CHANNEL，则直接return 了，会导致该类型的channel不能销毁，

16、一直占用底层资源。3、旧demux中的602行HI_UNF_DMX_OpenChannel前有： /* 设置通道pid，每次open都必须重设，否则没数据，lixq */ ret = HI_UNF_DMX_SetChannelPID(pch-idx, pch-pid);新的demux中HI_UNF_DMX_OpenChannel前没有做SetChannelPID的操作。对比新旧demux代码并修改后，测试不卡了16、release_2009的库进入马赛克应用向右移动焦点两次或者三次，发生死机原因：创建窗口时申请空间的方法和销毁窗口时释放空间的方法没有对应解决方法：抓LOG,抓堆栈，分析log和

17、堆栈，找到死机原因，修改销毁窗口时释放空间的方法，使之与创建时申请空间的方法一致。 HI3110E平台播放马赛克问题17、长时间播放数视导航（视频马赛克）应用，移动焦点伴音切换慢（正常大概1秒）原因：音频缓冲区缓存了一部分数据，切换音频时由于缓冲区中的数据在继续处理，因此导致音频切换延迟解决方法：切换音频时，清除一下解码器中的缓冲数据，且使用关闭打印的库18、场景马赛克和视频马赛克只显示32路视频，首页与第二页都只显示32路视频原因：库里虚拟filter只有32个解决方法：分析Log,发现log中有大量的：././src/dvbcore/release_2009/proj-dvbcore/in

18、clude/./lib_dsmcc/dsmcc_oc_ctrl.c(1649) : assert failed! filter创建失败的打印。检查配置中是否加上宏NO_USE_SINGLE_PHYSICAL_FILTER，盒子物理filter一般是32个，有可能是这个宏导致。深入分析，是库里做了设置，修改代码，问题解决。高斯贝尔-NEC（40528）平台播放马赛克问题1、进入马赛克播放页面后，按菜单、返回和退出键页面都没跳转，还是停在播放页面原因：在退出ip方式的播放页面时，系统会设置demux的数据来源。该平台不支持此种方式解决方法：通过不断修改代码，缩小问题的代码范围，然后不断得编库测试找

19、到问题所在。最终定位在：去掉在退出ip方式的播放页面时，系统会设置demux的数据来源。取消设置后，测试发现，系统能正常直播、oc stream及mosaic的各种情况。 2、进入一级马赛克页面，视频能正常显示出来，进入二级马赛克页面，视频出不来，但有声音原因：平台窗口自适应未完善解决方法：通过修改代码及应用发现跟页面meta标签有关，最终定位到问题出现在平台窗口的自适应上，平台自适应中有一种情况没有考虑到，由平台完善窗口自适应功能接口高斯贝尔-NEC（40528）平台播放马赛克问题3、播放马赛克视频卡并且最下面四个视频卡住不动且出现花屏原因：1.ts连续计数位错误 - ts包头4个固定字节中

20、的最后4个比特位，此字段是随着每个具有相同pid值的传输流分组而递增。如果ts流中的adaption_field_control 等于00或者 10时，不该递增，也就是说等于 01或11时，同一pid分组的均需进行递增。且达到最大值0 x0f后，回卷为0。ts的PES长度大于64KB分包 - 当在源PES中，还没进行拆分PES，一帧数据长度大于64KB的，经过中间件处理重组ts后，解码输出视频时，会有出现丢帧（但不是所有的整一帧数据，只是后面紧随的同一帧数据丢失了）。也就是说当 第一个188个字节的ts包，包头前4个字节中的 pay_load_unit_start_indicator 为0 x01时，为1个单独的PES分组在ts分组中开始，然后后面紧随的 pay_load_unit_start_indicator 为0 x00的ts包后面的有效数据是同属前面的PES分组中的实际数据。但是中间件在一帧数据大于64KB时，进行采取了分包，意思是当大于64KB时，后面的数据会重新进行把本属同一帧的数据进行拆分，在ts上表现为把大于64KB的数据从ts上进行了重新组一个PES分