MV range for DM365 H264 encoder

Hi,

besides the MVx/MVy range, additionally I wanted to confirm the units for MVx and MVy values. Since the ME algorithm can support either Half PEL interpolation or Quarter PEL interpolation, I am still assuming that the MVx/MVy values are in Pixel (PEL) units. Is this correct?

Thanks,

--Gunter

Hi,

Prior to discussing MV ranges, can you please let me know which version of H264 encoder you are using?

This is because Normal ME is supported only when ENC_PRESET = USER_DEFINED and  encQuality = 1 (HIGH quality). In platinum codec release (2.00.00.09 version) HIGH quality support is depreciated because of performance reasons.

The platinum codec supports only encQuality = 0 (STD quality) and encQuality = 2 (LITE quality) both of which use Low power ME.

Coming to your query,

Normal ME: MVx values lie within +/- 29.75 integer pel. MVy values lie within +/- 23.75 integer pel.

Low Power ME(LPME): MVx values lie within +/- 29.75 integer pel. Since LPME uses a concept of vertical GMV, there is no defined range for MVy. It can point anywhere within the frame.

It is only for theoretical discussions we refer to integer pels. The actual MVs returned by ME will be in quarter pels (INT pel x 4).

Rgds, mahant

Mahant,

i got the MV values as attached in H264 platinum codec 2.00.00.09

is these values are correct ? by using the MV values how to findout the direction.

Hi Sujit,

I had a look at the MV-SAD dump you had shared.

The MVs and SAD values are not fine. There seems to be some problem from where (which buffer?) these values are read.

Please have a look at section 4.2.2.2 of user guide for details related to this.

For more info:

http://processors.wiki.ti.com/index.php/Using_MV_SAD_Info_of_DM365_encoder_in_Application

Rgds, mahant

Mohant,

following is the piece of code used by me for getting the NV data.

--------------------

#ifdef MVDATA

 FILE* SadMvFilePtr;
 char fileName[64] = {0, };
 static int count = 0;
 char bWriteSADandMV = 1;

 if (count < 20) {
  snprintf(fileName, 63, "sadmvinfo.txt");
  SadMvFilePtr = fopen(fileName, "w+");
              if (SadMvFilePtr) {
                   if(bWriteSADandMV && (m_pDynParams->mvSADoutFlag == 1))
                  {
                       XDAS_UInt32 cntRow, cntCol, cnt;
           XDAS_Int32 *puiSadMVinfo;
  
           if (m_pDynParams->sliceSize <= 0)
                     puiSadMVinfo = (XDAS_Int32*)outBufDesc.bufs[1];
                       else
                           puiSadMVinfo = (XDAS_Int32*)outBufDesc.bufs[2];
    
           if (m_pParams->entropyMode || !(m_pParams->encQuality))
               puiSadMVinfo = (XDAS_Int32*)outBufDesc.bufs[1];

                       fprintf(SadMvFilePtr, "Frame : %d\n", count);
   
                       for(cntRow = 0; cntRow < (inBufDesc.frameHeight >> 4); cntRow++)
          {
        cnt = cntRow * 2 * (inBufDesc.frameWidth >> 4);
                    for(cntCol = 0; cntCol < 2 * (inBufDesc.frameWidth >> 4); cntCol+=2)
                      {
                        fprintf(SadMvFilePtr, "Mvx = %d, Mvy = %d, SAD = %d\n",
       (short)(puiSadMVinfo[cnt + cntCol] & 0x0000FFFF),(puiSadMVinfo[cnt + cntCol] >> 16),
                        (*((XDAS_Int32 *)(puiSadMVinfo) + cnt + 1 + cntCol)));
                      }
          }
                 }

    fclose(SadMvFilePtr);
          SadMvFilePtr = 0;
          count++;
           }  
 }

#endif

---------------------

i refered to the example source file for the above code but could not understand how mvx amd mvy values are collected.

is there any thing wrong in the code.

Hi Sujit,

Sorry for the delayed reply. Any update on this?

From the dump you have shared, it seems that you are reading a wrong buffer. The initial values 1920 and 1080 indicate the inputWidth and inputHeight encoded. Hence the buffer used for MV-SAD dumping is wrong.

What is encoder settings being used? Do you enable Multiple slices (MS) ?

I think there is a problem in above code when MS is enabled.

Rgds, mahant

Hi Mahant,

slice level encoding is been enabled.

i don't know how the MV values are stored, thats why i assumed the source code in *_stp.c file's MV data collection is right and used that.

if that doesn't seems correct can you please provide me the piece of code of write the MV data from the buffer.

i don't think any problem with my buffer, only thing is they way i am reading as per *_stp.c file might be wrong.

Hi Sujit,

Can you share the encoder settings? I can suggest changes depending on this.

Rgds, mahant

following are encoder setting parameters.

------ STATIC PARAMETERS -----------
 videncParams.encodingPreset =2
 videncParams.rateControlPreset =1
 videncParams.maxHeight =1536
 videncParams.maxHeight =2048
 videncParams).maxFrameRate =20000
 videncParams.maxBitRate =10485760
 videncParams.inputChromaFormat =9
 videncParams.reconChromaFormat =9
 videncParams.dataEndianness =1
 videncParams.maxInterFrameInterval =0
 videncParams.inputContentType =0
 meAlgo  =0
 enableVUIparams =0
 enableVUIparams =0
 levelIdc =40
 entropyMode =0
 transform8x8FlagIntraFrame =1
 transform8x8FlagInterFrame =1
 seqScalingFlag  =1
 encQuality =2
 enableARM926Tcm =0
 outputDataMode =1
 sliceFormat =1
 enableDDRbuff =0
 sliceMode  =3

------ DYANAMIC PARAMETERS -----------
 sizeof(IH264VENC_DynamicParams) =212
 videncDynamicParams.inputHeight =1536
 videncDynamicParams.inputWidth =2048
 videncDynamicParams.targetBitRate =10485760
 videncDynamicParams.intraFrameInterval =15
 videncDynamicParams.generateHeader =0
 videncDynamicParams.captureWidth =2048
 videncDynamicParams.captureWidth =20000
 videncDynamicParams.refFrameRate =20000
 videncDynamicParams).forceFrame =-1
 videncDynamicParams.mbDataFlag =0
 videncDynamicParams.interFrameInterval =0
 maxBitrateCVBR =0
 rcAlgo =0
 sliceSize =96
 airRate =0
 interPFrameQP =8
 interPFrameQP =8
 initQ =-1
 rcQMax =51
 rcQMin =8
 rcQMaxI =51
 rcQMinI =8
 enableROI =0
 mvSADoutFlag =1
 metaDataGenerateConsume =0
 maxDelay =2000
 lfDisableIdc =0
 enableBufSEI =0
 enablePicTimSEI =0
 perceptualRC =1
 resetHDVICPeveryFrame =1

Hi Sujit,

Can you try this out at your end and share the MV-SAD dumps?

#ifdef MVDATA

 FILE* SadMvFilePtr;
 char fileName[64] = {0, };
 static int count = 0;
 char bWriteSADandMV = 1;

 if (count < 20) {
  snprintf(fileName, 63, "sadmvinfo.txt");
  SadMvFilePtr = fopen(fileName, "w+");
              if (SadMvFilePtr) {
                   if(bWriteSADandMV && (m_pDynParams->mvSADoutFlag == 1))
                  {
                       XDAS_UInt32 cntRow, cntCol, cnt;
                       XDAS_Int32 *puiSadMVinfo;
  
                      puiSadMVinfo = (XDAS_Int32*)outBufDesc.bufs[1];

                       fprintf(SadMvFilePtr, "Frame : %d\n", count);
   
                       for(cntRow = 0; cntRow < (inBufDesc.frameHeight >> 4); cntRow++)
                      {
                          cnt = cntRow * 2 * (inBufDesc.frameWidth >> 4);
                         for(cntCol = 0; cntCol < 2 * (inBufDesc.frameWidth >> 4); cntCol+=2)
                         {
                            fprintf(SadMvFilePtr, "Mvx = %d, Mvy = %d, SAD = %d\n",
                             (short)(puiSadMVinfo[cnt + cntCol] & 0x0000FFFF),(puiSadMVinfo[cnt + cntCol] >> 16),
                             (*((XDAS_Int32 *)(puiSadMVinfo) + cnt + 1 + cntCol)));
                        }
                     }
                 }

         fclose(SadMvFilePtr);
          SadMvFilePtr = 0;
          count++;
           }  
 }

#endif

Please note that this change is not generic. It is done looking at the encoder settings at your end.

We can come up with a generic code once this starts working.

Rgds, mahant

Thanks Mahant,

attached thMV data file as per the changes.

please look in to it if it is correct or not.

Please attach the file Sujit.

Rgds, mahant

Sorry Mahant,

Ti website had some problem sience last 3-4 hours.

attached the file again.

Mahant,

as per the current data weg index 1 output buffer,as sugeested by you.

but in the users guide following information is available which says if mulitiple slices is enabeled the mv data is in output buffer with index 2.

-----------------

The MV and SAD is dumped in the

outBuf. The extra buffer is requested during XDM_GETBUFINFO call. If multiple slice is on, then MV-SAD information is in the index 2 of the buffers pointed by XDM_BufDesc *outBufs and index 1 is for packet size information. If multiple slice is off, the MV-SAD is dumped in index 1 of buffer pointers. Index 0 is always used for bit-stream data. MV SAD information is in the following format:



Word0: MVy[bit 31-16]:MVx[bit 15-0]

Word1: SAD [bit 31-0]

-----------------

Hi Sujit,

The MV-SAD dump looks fine now. Looks like the user-guide update for this is missing.

The multiple slice (MS) mentioned in user guide referred to slices based on slice sizes. This was supported in encQuality = 1 mode, which has been depreciated. MS based on rows or number of macro-blocks does not require ant output buffer.

Referring to below diagram,

1. outBuffer[0] - always used for bitsteam data

2. outBuffer[1] - used if MV-SAD dump is enabled(as sliceMode = 1 is not supported)

3. outBuffer[2] - used if simple 2 pass is enabled

Please find below the updated output buffer details:

Rgds, mahant

Please note that all the explanation provided is applicable to only 2.00.00.xx releases.

Rgds, mahant

thank you very much mahant,

my next point is

1 . as you said in this thread earlier that the MVx values in platinum Codec must be between +/- 29.75 and MVy no defined range.

but as per the MV's we got MVx values are not always between +/- 29.75 ?

2. i want to find out the direction from the Mv's. How can i achieve it, as the Mv's are based upom each macro block. are we getting 1 MVx and MVy cordinate based upon the best SAD value of each Macroblock ?

Hi Sujit,

Regarding 1: With +/- 29.75 I mean in integer pel. The MVs returned by ME will be in quarter pel. So the limit is (+/- 29.75 x 4) = 119.

Regarding 2: The MVs returned are in macro block (MB) basis. The dump contains 1 MVx and MVy per MB based on least SAD position for that MB.

Rgds, mahant

Mahant,

thanks for detailed explanation. sorry for late reply as i was busy with some other issue.

if i want to find out the direction of each macroblock from the motion vectors i got, what should i do.

is it simply tan inverse of Mvy/Mvx ?

or

there is some specific algorithm for detecting the direction from the motion vectors ?

Mahant

one more question. the what is the macro block search happens ?

i mean the search area, is it like +/- 16 MB's as with reference MB or +/-8 or how many ?

Hi Sujit,

I am not aware of any specific algorithm for detecting the motion direction.

Inverse tan might be a simple approach, but it depends on the application requirement i.e. with what accuracy you want the direction. I'll let you know if I can think of something on this.

I didn't get the question in your latest post. Can you re-state it?

Rgds, mahant

there is typo mistake in my post. may be because of thaquestion was not clear.

my point is while searching the best match macroblock, what is the serch region?

how many macroblocks are serached in each direction to find a best match.

Hi Sujit,

As indicated in my previous post (same thread),

In the horizontal direction we search +/- 32 pixels and +/- 14 pixels in vertical direction.In vertical direction we make use of global motion vectors thereby dynamic vertical search range will be higher.

Same data can be interpreted in terms of MBs.

Rgds, mahant