VICP Algorithms and Codecs Integration h264enc + jpegenc + deinterlacer?

Zack,

zack said:

we want to configure the  h264 not use the VICP. does just configure the

    eparams->enableARM926Tcm = 0;
    eparams->enableDDRbuff = 1;

is OK?

Yes, the above settings are correct for your requirement.

zack said:

Now the h264enc can run with the dei. and the jpegenc also can run with dei. But we can't get them run together. If we put the h264enc dei jpegenc all in the alg_imcop_lock, they can run together. but video is not smooth.

What do you mean by video not being smooth? As you would know, when H.264 enc, JPEG enc and DEI all are running, the DDR load would increase and also your systme might not be able to hit the realtime performance. I dont know the resolution you are trying but the realtime performance can be a reason why capture might drop frames and resulting in jerks in the video. you can send the video and we can try to look at it to answer your question.

Also, i can suggest you two options:

1. reduce the resolution and test the system again

2. reduce fps of jpeg enc and see if H.264 stream becomes better.

Please let us know the performance of each algorithm/codec in your system.

Regards,

Anshuman

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

Thanks Anshuman,

1. The    

 eparams->enableARM926Tcm = 0;
 eparams->enableDDRbuff = 1;

can 't work for us. when configured this. the video  will stop(From the windows VLC). it seems that the encode crashed. And i have not fixed this now.

2. When i don't enable the above. and use the     alg_imcop_lock lock the h264enc dei and jpegenc for video process, all can work.

test result:

DEI (D1) -- > resize  --> h264enc (D1)    --> network

              |

              -- > resize  --> jpegenc (D1)      --> network

when use the above, open two VLC  on windows, the video is not smooth. but when change the jpegenc to VGA or CIF, the video in VLC is smooth. it seems that system don't have resource.

DEI (D1) -- > resize  --> h264enc (D1)    --> network

              |

              -- > resize  --> jpegenc (VGA or CIF)      --> network

Zack

Zack,

Your point #2 shows that it is potentially limited on resources on DM365. BTW, can you tell me the frequency of ARM and DDR on your device configuration?

Regards,

Anshuman

Thanks,

We do these test on TI DM365EVM, and the frequency of ARM and DDR are default.

Zack

What is the DDR clock on your setup? I assume it should be 243 MHz but you can check with the boot up messages that are printed on console. I would assume D1 H.264 + D1 JPEG  + D1 deinterlacing should have worked on the system at 30 fps. I would suggest you should do some profiling and tell us how much is the performance for each process call. I suspect that the system load (not just codec) is causing these issues at your end.

Regards,

Anshuman

Thanks.

Yes, just we test the DDR clock, the clock is 240M.

Do you mean that if don't let  the H264 release the VICP resource, D1 H.264 + D1 JPEG  + D1 deinterlacing will be OK by use the process g_alg_imcop_lock?

Thanks

Ideally, if you run each algorithm/codec in sequence also, you should be able to run it with the required performance. This means you can put all the algorithms in same scratch group Id and might not need semaphore also.

If you plan to run DEI in parallel with H.264, then you have to use the option of releasing the VICP buffers from H.264 and using g_alg_imcop_lock, as you are doing currently.

Regards,

Anshuman

Thanks,

How to do profiling? Use the oprofile or other tools ?

Zack

Thanks,

We will try this method.

Zack