hi3536 VDEC 创建channels问题

本帖最后由 ngswfx 于 2016-5-11 18:48 编辑

HI_MPI_VDEC_SetChnParam(0,…)
HI_MPI_VDEC_StartRecvStream(0)
摧毁channel 0， 我是用下面这种方式：
HI_MPI_VDEC_StartRecvStream(0)
HI_MPI_VDEC_DestroyChn(0)。

这个动作不对呀，你笔误吧，关闭通道前要停止接收，HI_MPI_VDEC_StopRecvStream(0)，并且保证HI_MPI_VDEC_SendStream不会被调用到。

////////////////////////////////////可以明确的告诉你，只要过程合理，不是超级频繁，一分钟为量级，你来回折腾1天，这个通道的MPI也不会有事。当然，要是MMZ内存不够了，肯定失败。

我在数据回调中，直接根据过来流有没有解码出数据，来回从CIF-D1-720-1080不停切换某一个通道的解码规格，直到能解码得到YUV，工作都没事。

////////////////另外增加一个保护，用一个全局变量，例如bVdecChlOpened[0]=true or false; 来记录创建或者销毁。保证销毁过程中，或者创建前，不会输入数据到解码器HI_MPI_VDEC_SendStream。

///////////每次流程重复流程
HI_MPI_VDEC_CreateChn
HI_MPI_VDEC_GetPrtclParam
HI_MPI_VDEC_SetPrtclParam
HI_MPI_VDEC_SetChnParam
HI_MPI_VDEC_StartRecvStream

送数据

暂停送数据

HI_MPI_VDEC_StopRecvStream(VdChn);
HI_MPI_VDEC_DestroyChn(VdChn);

////////////////////////////////////////////////////////////////////////////////做解码，最怕的就是来回轮切图像，能把人郁闷死。不过还好，海斯的MPI还是比较结实的。只需要考虑自己线程取流断流的资源分配问题。

//MPI解码器通常没事。如果明确是同一种格式流，还有一种做法能规避资源释放问题：

//那就是不释放。不管是不是一路同一个图像，直接往里面送就可以了，对MPI VDEC解码器来说，他可不区分到底是那个IPC的图像，他只认关键帧。海斯MPI少了一个清空解码器缓冲的函数，要是有就更好了。换流仅仅需要清空一次解码器缓冲，这样保险些，应该会更稳定些。目前的风险是，送入另外一个IPC数据前，解码器缓冲里面还有部分数据（H264的机制决定的），其实底层会过滤掉的，但有几率会花一下屏。咱们仅仅需要尽量做到，换IPC数据后，第一个送入的数据包是一个关键帧，这样问题几率会小很多。

是我的笔误，是HI_MPI_VDEC_StopRecvStream(VdChn);
HI_MPI_VDEC_GetPrtclParam
HI_MPI_VDEC_SetPrtclParam 这两个mpi hi3536文档没有讲到

现在是，我去摧毁channel时，没有出现任何错误。

HI_S32 SAMPLE_COMM_VDEC_Stop(HI_S32 id)
{
    HI_S32 i = 0, max= 20;       
        VDECH *d = get_vd(id);
        if(!d)
                return 0;
               
        vdec_reset(id);
        while(!flush_vdec(id))
        {
                i = 0;
                while(!flush_vdec(id))
                                if(i++ >10000)
                                        break;
                usleep(10000);
                LOG("Flush iteration %d", i);
        }       
        LOG("Vdec flushed after %d iterations", i);
        for(i=0; i                 {
                        if(!HI_MPI_VDEC_StopRecvStream(d->vdec))
                                break;
                        usleep(50000);
                }
        if(i==max)
        {
                vdec_status(id);
                CHECK_CHN_RET(HI_MPI_VDEC_StopRecvStream(d->vdec), d->vdec, "HI_MPI_VDEC_StopRecvStream");      
    };
        LOG("HI_MPI_VDEC_StopRecvStream (%d) called for channel %d ", id, d->vdec);
        if(1)
        {
                mutex_lock(&chn_m);
                LOG("Destroying channel %d, hw channel %d", d->id, d->vdec);
                int s32Ret = HI_MPI_VDEC_DestroyChn(d->vdec);
                mutex_unlock(&chn_m);
                CHECK_CHN(s32Ret, d->vdec, "HI_MPI_VDEC_DestroyChn");
        }
       
    return HI_SUCCESS;
}

本帖最后由 ngswfx 于 2016-5-11 22:45 编辑

[quote][url=forum.php?mod=redirect&goto=findpost&pid=29950&ptid=11286]seymour 发表于 2016-5-11 19:10[/url]
是我的笔误，是HI_MPI_VDEC_StopRecvStream(VdChn);
HI_MPI_VDEC_GetPrtclParam
HI_MPI_VDEC_SetPrtclPar ...[/quote]

这是配置解码器参数的，不是出问题关键点   MPI1.0里面的  3.0里面是那个GetProtocolParam

本帖最后由 ngswfx 于 2016-5-11 21:10 编辑

[quote][url=forum.php?mod=redirect&goto=findpost&pid=29951&ptid=11286]seymour 发表于 2016-5-11 19:44[/url]
HI_S32 SAMPLE_COMM_VDEC_Stop(HI_S32 id)
{
    HI_S32 i = 0, max= 20;       
[/quote]

这些usleep和循环看得头大，感觉比较危险。你可以测试一下SAMPLE_COMM_VDEC_Stop时间占用。尽量控制在1ms以内完成。任何长时间等待，尤其在流回调里面都是危险的，因为40ms后，数据还会触发，如果被阻塞了，连锁反应，不异常才怪，弄不好，还把IPC搞死了:lol 。

////////////////////////////////////////////////////////////////////////////////////
我没这么干过。感觉这个SAMPLE_COMM_VDEC_Stop搞得太费劲。

这不会是海斯给的范例代码吧？

直接在下面这个基础上改成关闭一个通道不就可以了，简单高效。创建通道时再来检查，能否创建成功。
HI_S32 SAMPLE_COMM_VDEC_Stop(HI_S32 s32ChnNum)
{
    HI_S32 i;       

    for(i=0; i     {
        CHECK_CHN_RET(HI_MPI_VDEC_StopRecvStream(i), i, "HI_MPI_VDEC_StopRecvStream");      
        CHECK_CHN_RET(HI_MPI_VDEC_DestroyChn(i), i, "HI_MPI_VDEC_DestroyChn");
    }

    return HI_SUCCESS;
}

断流，我就只用了2个函数，不做返回检查，也不做状态检查。也不延时等待，默认认为肯定销毁了。

如果创建的时候不成功，才检查，如果创建失败，尝试再次销毁，然后重复3次，如果还失败，检查MMZ剩余内存够不够，如果不够，不管了（由于内存不够导致的解码通道创建失败，这个无解，顶多全局检查一遍所有解码通道，重新将浪费内存的解码通道释放，例如当前解码的图像是720的，而创建的是1080P的解码通道。还有一种情况是，这个通道根本没有码流，直接释放，开启CIF解码，送入一个CIF 264数据，显示logo,或者干脆黑屏，也可以不导入数据，直接关闭通道，释放内存，由于VO没有释放，此时这个通道图像静止于最后图像。这部分工作，我这边有个主线程里面检查所有解码通道当前解码图像格式，尽量用最低解码格式，节约内存，解码超级费内存，1个1080估计要用约20M内存），如果内存足够，还不成功，估计MPI异常，程序重启或者设备重启。

/////////////////////////不过这不排除，3536和3520D MPI部分，结实程度有差异，我一直搞3520D，没搞过3536。但感觉不会这么差，几次重新 创建就不行了。



mutex_lock(&chn_m);
                LOG("Destroying channel %d, hw channel %d", d->id, d->vdec);
                int s32Ret = HI_MPI_VDEC_DestroyChn(d->vdec);
                mutex_unlock(&chn_m);

这部分，我也不理解，你锁定这个干什么呀？  chn_m还是个全局变量，要是有128个还好说，否则，一个时刻，只允许一个通道被释放。其他释放通道通道都在这里等待。如果释放和创建不是线性执行，是在不同线程里面的动作，这肯定要出问题的。
这边还没有释放掉，其他地方已经在开始创建了。

建议你直接把函数改成下面这种简单的测试一下。
HI_S32 SAMPLE_COMM_VDEC_Stop(HI_S32 s32ChnNum,bool bSupportReleaseAgain=false);
HI_S32 SAMPLE_COMM_VDEC_Stop(HI_S32 id,bool bSupportReleaseAgain)
{
        //如果仅仅允许释放一次，这个要看底层能不能这么配合，也就是释放一次如果失败，还可以调用，估计应该不支持多次释放，首先是没必要，写函数不会这么做的，既然调用了释放，如果没有释放掉，再次释放，也不会释放掉的。
        //即便异步非阻塞释放，既然状态已经下发，再次调用，也没有实质意义。
        if(!bSupportReleaseAgain){
                if(!bDecChlInted[id])
                        return  HI_SUCCESS;
        }
        HI_MPI_VDEC_StopRecvStream(id);
        HI_MPI_VDEC_DestroyChn(id);
        bDecChlInted[id]=false;  //下次开启通道时，判断这个的状态，如果为true,通道创建是好的，不用再次创建了。
        return HI_SUCCESS;
}
平时直接调用SAMPLE_COMM_VDEC_Stop(i);   如果销毁了，还是不能创建成功，尝试三次 SAMPLE_COMM_VDEC_Stop(i,true);
//////////////////////////////////////////

非常感谢ngswfx的意见，我按照这方式测试下。:handshake