Unable to create an instance for H264 encoder

Hi Peregrinus ,

Can you please tell which version of Codec you are using? Also please share encoder config which you are using?

Please go through below link for modification that needs to be done to integrate codec to  DVSDK 2.1 demo.

http://processors.wiki.ti.com/index.php/Migration/Integration_Guide_for_DM36x_H.264_version_2.x_codecs

 

Hi Ritesh ,

   yes I tried the ver 2 of the codec but I was unable to retrieve the ver 2.24.03 of the linuxutils (I have the ver 2.24.02) and the xdais 6-25-02-11 (I have the 6_24). I any case I have the lastest release of the SDK (2-10-01-18), I searched a lot in the TI pages but I was unable to find these components.

My application load the decoder fist, then the encoder following the trace provided by the encodedecode demo. While using the old H264 codec ver 1 I can at least instantiate the decoder, with the version 2 also the decoder fails, maybe because I have the wrong linuxutils and xdais.

 

 

 

Hi Ritesh,

 thank you for the support. I made the following steps:

- installed the right version of the components in the dvsdk (framework, linuxutils and xdais);

- made all the changes in the .cfg and in the code as described in the migration guide (I found odd to modify the code for the encode and the decode demos but not for the encodedecode);

- recompiled dvsdk (and modules) with the ver 2.0 of the h264 codec;

- modified the loadmodules.sh script as suggested in the migration guide;

But I am unable to instantiate the decoder which in the first release was ok, since at the beginning I had troubles with the encoder (now I don't arrive at this point). It seems that algNumAlloc can not allocate 14 recs. (Needed more heap? how can I provide it? I have the same memory as in the evm dm365 board)

Below the trace after and before the codec upgrade.

I am not sure also about this two lines:

var ALG_MEM = xdc.useModule('ti.sdo.ce.alg.Settings');
ALG_MEM.useHeap = true;

In any case even if I comment these,  there is no improvement.

I attached also the .cfg file.

8267.vdctfdsply_cfg.txt

 

 

DECODER ver 2.0 NOT WORKING:
Create video decoder.
@1,074,013us: [+0 T:0x40d8e490 S:0x40d8db54] ti.sdo.ce.video2.VIDDEC2 - VIDDEC2_create> Enter (engine=0x499cf8, name='h264dec', params=0x40d8dcc8)
@1,074,353us: [+0 T:0x40d8e490 S:0x40d8db24] CV - VISA_create(0x499cf8, 'h264dec', 0x40d8dcc8, 0x2484, 'ti.sdo.ce.video2.IVIDDEC2')
@1,074,563us: [+0 T:0x40d8e490 S:0x40d8da24] CV - VISA_create2(0x499cf8, 'h264dec', 0x40d8dcc8, 0x38, 0x2484, 'ti.sdo.ce.video2.IVIDDEC2')
@1,074,829us: [+0 T:0x40d8e490 S:0x40d8da0c] OM - Memory_alloc> Enter(0x30)
@1,075,008us: [+0 T:0x40d8e490 S:0x40d8da0c] OM - Memory_alloc> return (0x496730)
@1,075,163us: [+0 T:0x40d8e490 S:0x40d8d9e4] ti.sdo.ce.alg.Algorithm - Algorithm_create> Enter(fxns=0x36b094, idma3Fxns=0x0, iresFxns=0x36b030, params=0x40d8dcc8, attrs=0x40d8db14)
@1,075,329us: [+0 T:0x40d8e490 S:0x40d8d9cc] OM - Memory_alloc> Enter(0x10)
@1,075,478us: [+0 T:0x40d8e490 S:0x40d8d9cc] OM - Memory_alloc> return (0x4aab08)
@1,075,627us: [+0 T:0x40d8e490 S:0x40d8d99c] ti.sdo.ce.alg - ALG_create> Enter (scratchId=1, fxns=0x36b094, parentAlg=0x0, params=0x40d8dcc8)
@1,075,881us: [+2 T:0x40d8e490 S:0x40d8d99c] ti.sdo.ce.alg - ALG_create> algNumAlloc 14 memory recs
@1,076,175us: [+7 T:0x40d8e490 S:0x40d8d9e4] ti.sdo.ce.alg.Algorithm - Algorithm_create> Algorithm creation FAILED; make sure that 1) alg params are correct/appropriate, 2) there is enough internal and external algorithm memory available -- check DSKT2 settings for heap assignments and scratch allocation
@1,076,378us: [+0 T:0x40d8e490 S:0x40d8d9cc] ti.sdo.ce.alg.Algorithm - Algorithm_delete> Enter(alg=0x4aab08)
@1,076,534us: [+0 T:0x40d8e490 S:0x40d8d9ac] OM - Memory_free> Enter(0x4aab08, 0x10)
@1,076,692us: [+0 T:0x40d8e490 S:0x40d8d9ac] OM - Memory_free> return (0x1)


DECODER ver 1.0  WORKING:
Create video decoder.
@1,582,835us: [+0 T:0x40d85490 S:0x40d84b8c] ti.sdo.ce.video2.VIDDEC2 - VIDDEC2_create> Enter (engine=0x440cf8, name='h264dec', params=0x40d84dcc)
@1,583,105us: [+0 T:0x40d85490 S:0x40d84b5c] CV - VISA_create(0x440cf8, 'h264dec', 0x40d84dcc, 0x2484, 'ti.sdo.ce.video2.IVIDDEC2')
@1,583,300us: [+0 T:0x40d85490 S:0x40d84a5c] CV - VISA_create2(0x440cf8, 'h264dec', 0x40d84dcc, 0x1c, 0x2484, 'ti.sdo.ce.video2.IVIDDEC2')
@1,583,575us: [+0 T:0x40d85490 S:0x40d84a44] OM - Memory_alloc> Enter(0x30)
@1,583,772us: [+0 T:0x40d85490 S:0x40d84a44] OM - Memory_alloc> return (0x43d280)
@1,583,931us: [+0 T:0x40d85490 S:0x40d84a1c] ti.sdo.ce.alg.Algorithm - Algorithm_create> Enter(fxns=0x312ccc, idma3Fxns=0x0, iresFxns=0x312c74, params=0x40d84dcc, attrs=0x40d84b4c)
@1,584,095us: [+0 T:0x40d85490 S:0x40d84a04] OM - Memory_alloc> Enter(0x10)
@1,584,257us: [+0 T:0x40d85490 S:0x40d84a04] OM - Memory_alloc> return (0x451ce8)
@1,584,407us: [+0 T:0x40d85490 S:0x40d849d4] ti.sdo.ce.alg - ALG_create> Enter (scratchId=1, fxns=0x312ccc, parentAlg=0x0, params=0x40d84dcc)
@1,584,627us: [+2 T:0x40d85490 S:0x40d849d4] ti.sdo.ce.alg - ALG_create> algNumAlloc 14 memory recs
@1,601,114us: [+2 T:0x40d85490 S:0x40d849d4] ti.sdo.ce.alg - ALG_create> algAlloc returned numRecs=14
@1,601,368us: [+4 T:0x40d85490 S:0x40d849d4] ti.sdo.ce.alg - ALG_create>  Memory requested memTab[0]: size=0x400, align=0x80, space=0x11, attrs=0x1
@1,601,546us: [+4 T:0x40d85490 S:0x40d849d4] ti.sdo.ce.alg - ALG_create>  Memory requested memTab[1]: size=0x2200, align=0x80, space=0x0, attrs=0x0
@1,601,704us: [+4 T:0x40d85490 S:0x40d849d4] ti.sdo.ce.alg - ALG_create>  Memory requested memTab[2]: size=0x2200, align=0x80, space=0x11, attrs=0x1
@1,601,858us: [+4 T:0x40d85490 S:0x40d849d4] ti.sdo.ce.alg - ALG_create>  Memory requested memTab[3]: size=0xa80, align=0x80, space=0x11, attrs=0x1
@1,602,014us: [+4 T:0x40d85490 S:0x40d849d4] ti.sdo.ce.alg - ALG_create>  Memory requested memTab[4]: size=0xd00, align=0x80, space=0x11, attrs=0x0

 

You are right, the problem was in the parameters. According to the codec documentation both the H264 encoder/decoder support only the YUV_420_SP format.  Lines of code like the following I found in the encode demo (but the same is for the decode) carried me to think I could directly encode the YUV422ILE coming from the TVP5158.

 if (colorSpace ==  ColorSpace_YUV420PSEMI) { 
        params->inputChromaFormat = XDM_YUV_420SP;
    } else {
        params->inputChromaFormat = XDM_YUV_422ILE;
    }

So now I can instantiate the H264 encoder and decoder.  It does not work at the moment since I still have to fix the chroma format issues, I suppose. On this regards, might maybe you have on hand some example of  chroma format conversion? (I read it can done using IPIPE and resizer).

 

Thank you for the support.

 

Great, thank you Kenric!! 

 

Kenric Smith said:

You can use the resizer on the DM365 to do the color conversion.  I don't know what your input is or how you are running the previewer, but you can chain the resizer to the preview engine and supply the necessary configuration to the resizer.

Isn't it true that if you chain the resizer then the video will be deinterlaced?  So if you want interlaced video then you must call the resizer from your applicaiton.

John A

Hi John,

It is just the way resizer-chained capture driver is implemented that it ends up duplicating the fields in vertical direction and provides the de-interlacing effect. There are two ways you can overcome it.

1. Modifying the driver itself. It might be little tedious though.

2. Set output format size as 720x240, lineoffset as 1440 for each field. Do capture in field mode. This way you will get interrupt per field and you will get the field data after every DQBUF call. After this you have to interleave the fields in the application.

Regards,

Anshuman

Are these the only two ways to use the resizer?  Can't I capture the frames interlaced in UYVY without the resizer, and then use the resizer from my application to convert the frame 420 semi planer?

John A

Hi John, 

   yes you can. I am using the resizer not for resizing but for sampling conversion from UYVY to YUV420_SP. I don't see any side effect until now.

John,

John Anderson said:

Can't I capture the frames interlaced in UYVY without the resizer, and then use the resizer from my application to convert the frame 420 semi planer?

You can do the above. For this you will have to use non-chained mode of capture and use resizer in single-shot mode for color conversion. I thought you already were able to do that.

The was i had mentioned was to remove the "de-interlacing" effect in the chained mode capture where resizer was connected in continuous mode.

I hope it is clear now.

Regards,

Anshuman

 

Based on discussions earlier I'm able to capture in single-shot mode, but I haven't tried using the resizer to convert the video yet.  I was just comfirming that I'm on the right path before I put in the effort.

John A

Hi John,

The approach you talked about is very much possible and can solve your problem. The only adverse effect can be more DDR consumption as you could saved the extra write and read from DDR for the YUV422 data, if you used continuous mode operation.

But to keep things simple, i think you can do the single-shot mode approach that we have talked about and you are planning to try anyways.

Regards,

Anshuman

PS: Please mark this post as verified, if you think it has answered your question. Thanks.