Arm load is nearly 80% and can't achieve real-time when encode the video

what platform (DM355 or DM365) are you using? what video encode algorithm (MPEG2, MPEG4, H.264...)? what DVSDK version?  Are you using the encode demo included with the DVSDK or something else?  I am afraid I need this information to pin-point the problem...

platform:DM365

encode algorithm:H.264

dvsdk_2_10_01_18

Thanks in advance

The Text_showUnicode function is the same as Text_show , only to change it to support chinese.

I really can't slove this .

Could you give me some support?

so I have done some testing on my end, and when I do h.264 encode with the DVSDK demos (no changes), i get ARM load of ~22% while encoding 720p @ 30 fps.  I do know that earlier versions of our software had large ARM loads, so I suspect you may not be running the latest.  I would recommend you  install the latest DVSDK software again.

Firstly, thank you for your support.

Second,My dvsdk is the latest version.

I add some code to the capture.c in encode of demos(dvsdk_2_10/dvsdk_2_10_01_18/dvsdk_demos_2_10_00_17/dm365/encode).

I want to write some messages(time and location) to every frame. So I call the function as "Text_show" in Text.c(dvsdk_2_10/dvsdk_2_10_01_18/dvsdk_demos_2_10_00_17/packages/ti/sdo/simplewidget )

After capture get the frame, I do the function as follows.

if (Capture_get(hCapture, &hCapBuf) < 0)

        {

            ERR("Failed to get capture buffer\n");

            cleanup(THREAD_FAILURE);

        }

        BufferGfx_setColorSpace(hCapBuf,ColorSpace_YUV422PSEMI);

        Text_show(Font, "location:Beijing in china", FONT_SIZE, 40,

                         40, hCapBuf);

        getDate(envp->osd_args->date);// the date string fomat is YYYY-MM-DD(2009-11-18)

        Text_show(Font, envp->osd_args->date, FONT_SIZE, 40,

                         60, hCapBuf);

        BufferGfx_setColorSpace(hCapBuf,ColorSpace_YUV420PSEMI);

      ...................................................................

    The below code is unchanged.

    I check the arm load is too high (80%),Could you test it again and give me some reason?

Regards,

Weidong

I have testes again and same results.  FYI, actually I have tested the ARM load performace for other customers in the past as well.  In some cases customers believed they had the latest and a simple re-install of the software fixed the ARM load; I am not sure if this will be the case for you, especially since you mentioned you added some code.  I would recommend you test the original demo without your added code and see what ARM load you get.  If your added code is writting OSD data every frame (not the demo default), I can see how the ARM load may go up.  However, 80% seems awful high...if running the original demo does not bring this number down by quite a bit to say 25%, then I would recommend re-installing the software.

OK. I tested it as you advice that  using the original demo without added code. The arm load is about 25% and I think it works well.

I am actually writting the osd data to every frame. I know that the original demo only writing OSD about every 25 frame.

But my  requirement is writting the data to original video stream.

My aim is to show the data(date and location) when decode the video stream in PC.The code added also can show that I am writting the date and location data to  every frame.

In addition, if  only add the location data to every frame the arm load is about 60%.

If added all data(date and location) to every frame the arm load is about 80%.

Maybe it's normal for the arm load because the Text_Show consume much load.

If I want it can achieve real time and meet my requirement. What should I do?

two things to keep in mind are ARM load and DDR2 load; I believe you are running into issues with the first.  By default Linux threads are managed by Linux scheduler in a way were none of the threads get starved off; this includes many system threads (some which run at a little higher priority).  In addition, attributes such as a thread's "niceness" factor plays a role in which thread gets more time.  In conclusion, with the default Linux threads used in the demos, you cannot guarantee your thread will get a specific amount of time to do the work it needs to as the Linux scheduler may give that time you need to another system thread.  Therefore, when you combine 80% load plus Linux scheduler... the odds of getting the CPU time you need to do your work does not look good.  This is why many people say Linux is NOT a real-time operating system.

That said, there are "real-time" linux threads (same threads running at higher priority) which may be able to help; however, the topic of how these works and how the scheduler's behavior changes for these threads is beyond the scope of what I can quickly describe here.  I would recommend you try to find a good book on this topic. 

Additionally, the widget library is not optimized for production; this is a very simple library we used for demo purposes; you may want to dig into the code and see if there are ways to optimize (perhaps minimize memory copies which take precious CPU time...).  

anyway, just a couple of ideas