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.

The effect between DRV_frameCopy() and ALG_vidDecRun() functions

Other Parts Discussed in Thread: TEST2

Hi everyone,

I constructed three loop-repeated threads and let them run at the same time.
1.Stream thread: receive video packets in H.264 format from network and sends them to the packet queue.
2.Decode thread: get the packets in the queue and decode them to the transmission buffers by ALG_vidDecRun() function.
3.Display thread: get the video data from the transmission buffers and copy them to display buffers by DRV_frameCopy() function and then show them on screen.

The transferred video data are in the size 1024x768 per frame, but the transmission buffers have to be allocated as 1088x816 to receive the decoded data when ALG_vidDecRun() function is used to decode. The valid data are placed in the transmission buffers with the offset 24 in X and Y direction separately. The display buffers are allocated as 1024x768, so the DRV_frameCopy() function is used to crop the valid data(1024x768) from transmission buffers(1088x816) to display buffers(1024x768).

Decode thread:
+------------------ +
|                          |
|    video packet     |
|                          |
+------------------ +
           |
           | ALG_vidDecRun()
           |
          \|/
+------------------ +
|                           |
| transmission buffer |
|     1088x816         |
+------------------ +

 

Display thread:
+------------------ +
|                           |
| transmission buffer |
|     1088x816         |
+------------------ +
           |
           | DRV_frameCopy()
           |
          \|/
+------------------ +
|                          |
|    display buffer     |
|      1024x768        |
+------------------ +

There are three transmission buffers which are transmitted between Decode thread and Display thread through OSA functions(Ex. OSA_bufGetFull(), OSA_bufPutFull())

Condition:
Video processing in above structure is not fast enough to fit the frame rate of network stream. The Decode thread and Display thread work at a much slower rate, but Stream thread works fine. Then I made some tests as following.

Test1.
Create one temporary buffer in size 1088x816 to replace transmission buffers as the source buffer when executing DRV_frameCopy() function and keep all the OSA functions for transmission buffers.
Result: Decode thread and Display thread are still at a slow rate.

Test2.
Follow Test1 and modify temporary buffer to the size 1024x768
Result: Every thread works fine to fit the frame rate of network stream.

Test3.
Follow Test2  and execute DRV_frameCopy() repeatedly for three times in one Display thread run
Result: Every thread works fine to fit the frame rate of network stream.

Note: It's verified that the slow rate is caused by the ALG_vidDecRun() function that works for much longer time.

Problem:
Why the size of source buffer that used by DRV_frameCopy() can effect the processing efficiency of ALG_vidDecRun() function so much, even it just becomes larger with a small value(1088x816 to 1024x768)? Is there any limitation of it?

[Our System Information]

DVSDK_2_10_01_18

JPEG Sequential Decoder Version 01.00.00

linux-2.6.18_pro500

framework_components_2_24

linuxutils_2_24_02