• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 406 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DM365 MPEG2 Codec Stalled

Kieran Bingham
Prodigy 65 points

Hi Guys,

We've got a DM365 system which we were running on the DVSDK2.10.
As there are improvements in the SDHC and USB controllers in the later kernels, we want to move to the newer DVSDK, and Arago kernel build.

 

I downloaded DVSDK3.10, and we added our platform to the 2.6.32 Arago kernel.
I can capture video, and display video on screen, so I know that our system is visibly functioning and running but alas I cannot encode any data.

I am using the "mcvip-encoder / av_server" code framework to capture and encode using the MPEG2 Codec, but the same occurs with the H264 codec too.

With CE_TRACE turned on, I see the following:

ENCODE: Ch 0 InBuf 0 OutBuf 0
ENCODE: pOutBuf->virtAddr 0x46150000
@0x01365d41:[T:0x451aa490] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process> Enter (handle=0x29ddb0, inBufs=0x451a9be8, outBufs=0x451a9d4c, inArgs=0x451a9d40, outArgs=0x451a9cb8)
@0x01365fb1:[T:0x451aa490] CV - VISA_enter(visa=0x29ddb0): algHandle = 0x29dde8
@0x01366127:[T:0x451aa490] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(alg=0x29dde8)
@0x0136627c:[T:0x451aa490] ti.sdo.ce.osal.SemMP - Entered SemMP_pend> sem[0x29d338] timeout[0xffffffff]
@0x013664aa:[T:0x451aa490] ti.sdo.ce.osal.SemMP - Leaving SemMP_pend> sem[0x29d338] status[0]
@0x013666e7:[T:0x451aa490] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Exit

So I can see that the thread enters the VISA VIDENC1_process call into the MPEG2 codec, but never exits.

I've traced this down and can see that it is waiting on an interrupt from the co-processor

MPEG2 Encode :
#0  0x4062e27c in ioctl () from /lib/libc.so.6
#1  0x000e7314 in VICP_wait ()
#2  0x000e332c in HDVICPSYNC_wait ()
#3  0x000ddf44 in MPEG2VENC_TI_Encode ()
#4  0x0007c91c in VIDENC1_process ()

I traced this down as Interrupt 10 - and I have verified that the interrupt is both enabled - and muxed correctly.

However the interrupt never arrives - - and we're always waiting on VICP_wait. :(

Can anyone suggest any reasons why the codec would not be starting on the new kernel ?
Would the memory maps of shared DTCM be different and prevent the co-processor loading?

Would there be any other muxings that might prevent the co-processor running?

I'm stuck - and can't get it to run - so just hoping someone might have some ideas !
I don't think there's any way I can debug the state of the codec further than the CE_TRACE - so I can't tell why the codec isn't running or what's wrong with it.

Regards

Kieran