• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 103 subscribers
  • Views 1383 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DM368: Hang when running H264 after MP4 without rebooting inbetween

KAL1
Prodigy 195 points

We have a problem with the H264 encoder: if we run an MP4 encode session *before* an H264 encode session, then the H264 encode hangs waiting on the HDVICP interrupt.

I can run MP4 after H264 without problem. e.g. the following steps show the failure mode:

1. Start H264 encode session -> works fine
2. Stop H264, then Start MP4 encode session -> works fine
3. Stop MP4 session, then Start H264 encode session -> hangs on HDVICPSYNC interrupt (HDVICPSYNC_EFAIL).

This happens with both the MP4 VICP and MP4 HDVICP encoders. It also seems that KTNF encodes affect H264 in a similar way. JPEG however works fine together with H264.

I am running all of the encodes serially. All codecs (H264, MP4, JPEG) are in the same scratch group ID, and I only use one thread to do encodes so there are no parallel encodes happening.

This is using the DVSDK 4.02.00.06. I also copied the whole codecs tree from RDK 3.1 but get the same problem.

I have checked our interrupt handling and the HDVICP interrupt is definitely not being generated. It looks like there is a problem inside the binary H264 encoder library that means starting a session after MP4 fails to set up the HDVICP properly and the interrupt does not occur.

We always set resetHDVICPeveryFrame=1. We normally set enableDDRbuff=0 because all codecs are in the same scratch group, but enableDDRbuff=1 does not help either.

We are not using Linux, we have ported much of the DVSDK to an RTOS. Most is working well except for this H264 issue. Unfortunately the H264 encoder is object code so we are having difficulty debugging further.

I received a new release of the H264 library from TI in February 2013 but this did not fix it.

Our H264 encode parameters are pasted below.

Many thanks.


		h264_ptr->params.videncParams.size = sizeof(IH264VENC_Params);
		h264_ptr->params.videncParams.maxWidth = imageWidth;
		h264_ptr->params.videncParams.maxHeight = imageHeight;
		h264_ptr->params.videncParams.maxInterFrameInterval = 1;
		h264_ptr->params.videncParams.inputChromaFormat = XDM_YUV_420SP;
		h264_ptr->params.videncParams.reconChromaFormat = XDM_YUV_420SP;
		h264_ptr->params.videncParams.maxBitRate = DAVINCI_H264_MAX_BITRATE;
		h264_ptr->params.videncParams.maxFrameRate = DAVINCI_H264_MAX_FRAMERATE * 1000;
		h264_ptr->params.videncParams.dataEndianness = XDM_BYTE;
		h264_ptr->params.videncParams.inputContentType = IVIDEO_PROGRESSIVE;
		h264_ptr->params.videncParams.rateControlPreset = IVIDEO_USER_DEFINED;
		h264_ptr->params.videncParams.encodingPreset = XDM_USER_DEFINED;
		h264_ptr->params.profileIdc = 66;
		h264_ptr->params.levelIdc = IH264VENC_LEVEL_40;
		h264_ptr->params.Log2MaxFrameNumMinus4 = 0;
		h264_ptr->params.ConstraintSetFlag = XDM_DEFAULT;
		h264_ptr->params.entropyMode = 0;
		h264_ptr->params.transform8x8FlagIntraFrame = 0;
		h264_ptr->params.transform8x8FlagInterFrame = 0;
		h264_ptr->params.enableVUIparams = 0;
		h264_ptr->params.meAlgo = 0;
		h264_ptr->params.seqScalingFlag =  0;
#ifdef USE_TCM
		h264_ptr->params.encQuality = 2;
		h264_ptr->params.enableARM926Tcm = 1;
#else
		h264_ptr->params.encQuality = 0;
		h264_ptr->params.enableARM926Tcm = 0;
#endif
		h264_ptr->params.enableDDRbuff = 0;
		h264_ptr->params.sliceMode = 0;
		h264_ptr->params.numTemporalLayers = 0;
		h264_ptr->params.svcSyntaxEnable = 0;
		h264_ptr->params.EnableLongTermFrame = 0;
		h264_ptr->params.outputDataMode = 1;
		h264_ptr->params.sliceFormat = 1;
		h264_ptr->dynamicparams.videncDynamicParams.size = sizeof(h264_ptr->dynamicparams);
		h264_ptr->dynamicparams.videncDynamicParams.inputWidth = imageWidth;
		h264_ptr->dynamicparams.videncDynamicParams.inputHeight = imageHeight;
		h264_ptr->dynamicparams.videncDynamicParams.targetFrameRate = DAVINCI_H264_MAX_FRAMERATE * 1000;
		h264_ptr->dynamicparams.videncDynamicParams.refFrameRate = h264_ptr->dynamicparams.videncDynamicParams.targetFrameRate;
		h264_ptr->dynamicparams.videncDynamicParams.targetBitRate = 0;
		h264_ptr->dynamicparams.videncDynamicParams.intraFrameInterval = gov_length;		
		h264_ptr->dynamicparams.videncDynamicParams.generateHeader = XDM_ENCODE_AU;
		h264_ptr->dynamicparams.videncDynamicParams.captureWidth = imageStride;
		h264_ptr->dynamicparams.videncDynamicParams.forceFrame = IVIDEO_NA_FRAME;
		h264_ptr->dynamicparams.videncDynamicParams.interFrameInterval = 0;
		h264_ptr->dynamicparams.videncDynamicParams.mbDataFlag = 0;
		h264_ptr->dynamicparams.sliceSize = 0;
		h264_ptr->dynamicparams.airRate = 0;
		h264_ptr->dynamicparams.intraFrameQP = quality;
		h264_ptr->dynamicparams.interPFrameQP = quality;
		h264_ptr->dynamicparams.initQ = quality;
		h264_ptr->dynamicparams.rcQMax = 51;
		h264_ptr->dynamicparams.rcQMin = 2;
		h264_ptr->dynamicparams.rcQMaxI = 51;
		h264_ptr->dynamicparams.rcQMinI = 2;
		h264_ptr->dynamicparams.rcAlgo = 2;
		h264_ptr->dynamicparams.maxDelay = 1000;
		h264_ptr->dynamicparams.aspectRatioX = 1;
		h264_ptr->dynamicparams.aspectRatioY = 1;
		h264_ptr->dynamicparams.lfDisableIdc = 0;
		h264_ptr->dynamicparams.enableBufSEI = 0;
		h264_ptr->dynamicparams.enablePicTimSEI = 0;
		h264_ptr->dynamicparams.perceptualRC = 1;
		h264_ptr->dynamicparams.idrFrameInterval = 0;
		h264_ptr->dynamicparams.mvSADoutFlag = 0;
		h264_ptr->dynamicparams.resetHDVICPeveryFrame = 1;
		h264_ptr->dynamicparams.enableROI = 0;
		h264_ptr->dynamicparams.metaDataGenerateConsume = 0;
		h264_ptr->dynamicparams.maxBitrateCVBR = 0;
		h264_ptr->dynamicparams.interlaceRefMode = 0;
		h264_ptr->dynamicparams.enableGDR = 0;
		h264_ptr->dynamicparams.GDRduration = 0;
		h264_ptr->dynamicparams.GDRinterval = 0;
		h264_ptr->dynamicparams.LongTermRefreshInterval = 0;
		h264_ptr->dynamicparams.UseLongTermFrame = 0;
		h264_ptr->dynamicparams.SetLongTermFrame = 0;
		h264_ptr->dynamicparams.VUI_Buffer = NULL;
		h264_ptr->dynamicparams.CustomScaleMatrix_Buffer = NULL;
		h264_ptr->dynamicparams.CVBRsensitivity = 0;
		h264_ptr->dynamicparams.CVBRminbitrate = XDM_DEFAULT;
		h264_ptr->dynamicparams.LBRmaxpicsize = 0;
		h264_ptr->dynamicparams.LBRminpicsize = 0;
		h264_ptr->dynamicparams.LBRskipcontrol = 0x50004;
		h264_ptr->dynamicparams.maxHighCmpxIntCVBR = 0;
		h264_ptr->dynamicparams.disableMVDCostFactor = XDM_DEFAULT;
		h264_ptr->dynamicparams.putDataGetSpaceFxn = NULL;
		h264_ptr->dynamicparams.dataSyncHandle = NULL;


  • 0
    TI__Expert 8465 points

    Hi

    Can you please tell your video resolution you are running for MPEG4 and H264?. And are you seeing hang at very 1st frame of H264? In our IPNC setup we tried running MPEG4 and H264 in above mentioned steps, ts running fine. We had issue with MPEG4-HDVICP codec + H264, it got resolved in 2.30.00.06 H264  codec version.

    You can refer http://e2e.ti.com/support/embedded/multimedia_software_codecs/f/356/t/210087.aspx

  • 0 in reply to Veeranna Hanchinal
    Prodigy 195 points

    Thanks for the reply.

    We see the problem using 1080P and 720P. I think we might sometimes get one or two frames out before it hangs, but not sure about that right now.

    The key thing seems to be not getting a HDVICPSYNC interrupt causing HDVICPSYNC_EFAIL. Because this is not on Linux we have our own VICP/HDVICP interrupt framework but it does seem to be solid: we've using MP4 and JPEG together continuously for months, as well as H264 and JPEG together. The problem seems to be some state left when the MP4 encoder has been used, which causes the interrupt to hang when switching from MP4 to H264.

    I am using H264 2.30.00.06, and I also previously tried with the h264Enable_hdvicp() function mentioned in that thread which unfortunately did not work. It sounds like that fix is now rolled into 2.30.00.06.

    Also we get the same problem with the VICP and HDVICP MP4 encoders - we cannot run H264 afterwards whichever MP4 encoder we use.

    Many thanks.

  • 0 in reply to KAL1
    TI__Expert 8465 points

    Hi,

    Here attaching debug library, can you please try with this once and send us log?.  And are you using your custom board? 

    8877.h264venc_ti_arm926.a.txt_debug.7z

  • 0 in reply to Veeranna Hanchinal
    Prodigy 195 points

    I have been digging deeper into this problem and found that the only way to start an H264 session after an MPEG4 session has run is if you close the MPEG4 session first. The important thing is that you have to call RMAN_freeResources() on the MP4 session before opening H264, otherwise the next H264 session will not start properly and will hang waiting for a HDVICPSYNC interrupt.

    I don't need MPEG4 and H264 to run simultaneously / multi-threaded, I am happy doing everything in one thread, e.g. one complete MP4 frame, then one complete H264 frame. I am using the same scratch ID for MPEG4 and H264 and using the standard algActivate()/algDeactivate() pair, but this is not enough: you must call RMAN_freeResources() on the MP4 session before you can start H264, which rules out having both MPEG4 and H264 sessions running.

    Reading this forum I see TI have tested JPEG and H264 together, but have they tested MPEG4 and H264 together?

    I've had a look at edma3_configArm.c and it looks like there are several problems with sharing EDMA resources between codecs in there. For example it frees EDMA channels even if there is more than one user (busy count == 2). It looks a bit like the MPEG4 and H264 don't play well together in terms of EDMA resource handling.

    The problem is the same if using the MPEG4 MJCP or HDVICP codecs. I'm setting resetHDVICPeveryFrame=1 when starting H264.

    Apologies for the delay responding, I have just come back to this project.

    Thanks for any advice.