• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 404 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.

Unable to get OMAP 3530 H.264 encoder pfNalUnitCallBack function to work

Don Zimmerman
Prodigy 30 points
Other Parts Discussed in Thread: OMAP3530

I'm arriving very late to the party for OMAP3530 low level software integration for the H.264 Encoder ...  I have the basic H.264 encoder working but have been stalled trying to get the "callback" function to work for breaking the encoded H.264 output in NAL packet format (with SPS/PPS as well).  I only see two unresolved TI threads on this that have been quiet over a year.

I was surprised to Google the entire planet Earth and not find a single reference to "pfNalUnitCallBack", but it is documented in a PDF file packaged with the codecs:

H.264 Baseline Profile Encoder on
OMAP3530
User’s Guide
Literature Number: SPRUET9
July 2009

in Appendix B.  The Appendix gives conflicting examples on the prototype of the function (the code example omits the "*pContext" argument which isn't well explained).

We would be extremely grateful if anyone at TI (or anywhere else) could shed light on how the callback function is supposed to be configured and work.

My code works fine with the callback set to NULL.  Below is a debug trace (with all debugging I could turn on which shows a call in VIDENC1_process() and the DSP dying instead of doing the next thing, like CN - NODE ...

First debug trace is from callback function pfNalUnitCallBack = NULL:

call VIDENC1_process()... @2,678,765us: [+0 T:0x403c6000] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process> Enter (handle=0x54960, inBufs=0x5263c, outBufs=0x5270c, inArgs=0x52720, outArgs=0x5272c)                                                        
@2,679,070us: [+4 T:0x403c6000] CV - VISA_getMaxMsgSize(0x54960): returning 0x1000                                                                                                                                                                                                     
@2,679,222us: [+5 T:0x403c6000] CV - VISA_allocMsg> Allocating message for messageId=0x000288eb                                                                                                                                                                                         
@2,679,405us: [+0 T:0x403c6000] CV - VISA_call(visa=0x54960, msg=0x413d4880): messageId=0x000288eb, command=0x0                                                                                                                                                                         
[DSP] @5,049,736tk: [+5 T:0x87f1242c] CN - NODE> 0x87f11e30(h264enc#0) call(algHandle=0x87f11ef8, msg=0x87305880); messageId=0x000288eb                                                                                                                                                 
[DSP] @5,049,820tk: [+0 T:0x87f1242c] OM - Memory_cacheInv> Enter(addr=0x86350000, sizeInBytes=101376)                                                                                                                                                                                  
[DSP] @5,049,987tk: [+0 T:0x87f1242c] OM - Memory_cacheInv> return                                                                                                                                                                                                                      
[DSP] @5,050,020tk: [+0 T:0x87f1242c] OM - Memory_cacheInv> Enter(addr=0x86368c00, sizeInBytes=25344)                                                                                                                                                                                   
[DSP] @5,050,099tk: [+0 T:0x87f1242c] OM - Memory_cacheInv> return                                                                                                                                                                                                                      
[DSP] @5,050,131tk: [+0 T:0x87f1242c] OM - Memory_cacheInv> Enter(addr=0x8636ef00, sizeInBytes=25344)                                                                                                                                                                                  
[DSP] @5,050,210tk: [+0 T:0x87f1242c] OM - Memory_cacheInv> return                                                                                                                                                                                                                     
[DSP] @5,050,244tk: [+0 T:0x87f1242c] OM - Memory_cacheInv> Enter(addr=0x86300000, sizeInBytes=327680)                                                                                                                                                                                 
[DSP] @5,050,650tk: [+0 T:0x87f1242c] OM - Memory_cacheInv> return                                                                                                                                                                                                      
[DSP] @5,050,689tk: [+0 T:0x87f1242c] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process> Enter (handle=0x87f11ef8, inBufs=0x87f1764c, outBufs=0x87f1771c, inArgs=0x87305a04, outArgs=0x87305a10)                                                          
[DSP] @5,050,787tk: [+5 T:0x87f1242c] CV - VISA_enter(visa=0x87f11ef8): algHandle = 0x87f11f30                                                                                                                                                                                    
[DSP] @5,050,836tk: [+0 T:0x87f1242c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(alg=0x87f11f30)                                                                                                                                                                               
[DSP] @5,050,886tk: [+0 T:0x87f1242c] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Exit                                                                                                                                                           
[DSP] @5,064,528tk: [+5 T:0x87f1242c] CV - VISA_exit(visa=0x87f11ef8): algHandle = 0x87f11f30                                                                                                                                                                 
[DSP] @5,064,605tk: [+0 T:0x87f1242c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter(alg=0x87f11f30)                                                                                                                                                                             
[DSP] @5,064,664tk: [+0 T:0x87f1242c] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Exit                                                                                                                                                   
[DSP] @5,064,710tk: [+0 T:0x87f1242c] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process> Exit (handle=0x87f11ef8, retVal=0x0)                                                                                                                                                        
[DSP] @5,064,771tk: [+0 T:0x87f1242c] OM - Memory_cacheWb> Enter(addr=0x86300000, sizeInBytes=327680)                                                                                                                                    
[DSP] @5,065,202tk: [+0 T:0x87f1242c] OM - Memory_cacheWb> return                                                                                                                                                                                                   
[DSP] @5,065,237tk: [+5 T:0x87f1242c] CN - NODE> returned from call(algHandle=0x87f11ef8, msg=0x87305880); messageId=0x000288eb                                                                                                                                                      
@2,692,986us: [+0 T:0x403c6000] CE - Engine_fwriteTrace> returning count [1998]                                                                                                                                                                                                         
@2,693,108us: [+0 T:0x403c6000] CV - VISA_call Completed: messageId=0x000288eb, command=0x0, return(status=0)                                                                                                                                                                      
@2,693,260us: [+5 T:0x403c6000] CV - VISA_freeMsg(0x54960, 0x413d4880): Freeing message with messageId=0x000288eb                                                                                                                                                                  
@2,693,382us: [+0 T:0x403c6000] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process> Exit (handle=0x54960, retVal=0x0)                                                                                                                                                                      
... return                                                                                                                                                                                                                                                                 
   DSP encoding output: frameType 0x3, frameSkip 0x0, bytes 439                                                                                                                                                                                                                   
call VIDENC1_process()... @2,696,770us: [+0 T:0x403c6000] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process> Enter ...

(and so on, all 61 frames encoded)

 

This is the comparable trace with only change being assigning the callback function:

call VIDENC1_process()... @3,053,013us: [+0 T:0x403c6000] XU - XdmUtils_validateExtendedStruct> Enter (pStruct=0x52720, minSize=0xc, name=inArgs
@3,053,318us: [+0 T:0x403c6000] XU - XdmUtils_validateExtendedStruct> return (0x1)
@3,053,440us: [+0 T:0x403c6000] XU - XdmUtils_validateExtendedStruct> Enter (pStruct=0x5272c, minSize=0x78, name=outArgs
@3,053,562us: [+0 T:0x403c6000] XU - XdmUtils_validateExtendedStruct> return (0x1)
@3,053,715us: [+0 T:0x403c6000] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process> Enter (handle=0x54960, inBufs=0x5263c, outBufs=0x5270c, inArgs=0x52720, outArgs=0x5272c)
@3,053,837us: [+0 T:0x403c6000] XU - XdmUtils_validateSparseBufDesc> Enter (bufDesc=0x5270c, name=outBufs
@3,053,959us: [+0 T:0x403c6000] XU - XdmUtils_validateSparseBufDesc> return (0x1)
@3,054,081us: [+4 T:0x403c6000] CV - VISA_getMaxMsgSize(0x54960): returning 0x1000
@3,054,172us: [+5 T:0x403c6000] CV - VISA_allocMsg> Allocating message for messageId=0x00028944
@3,054,356us: [+0 T:0x403c6000] CV - VISA_call(visa=0x54960, msg=0x413d4880): messageId=0x00028944, command=0x0

(it just stops here)

 

  • 0
    TI__Genius 17205 points

    I don't know the details about this particular codec, nor the field in question, but if this field is a "pointer to a fxn", and you're passing an ARM-side fxn address to a DSP-side codec, it's unlikely to work.  And I wouldn't be surprised if it resulted in a crash and/or MMU fault if the DSP codec tried invoking an ARM-side fxn... kinda like what you're seeing.

    This is loosely covered in the 'Constraints' section of this article - no ptrs in extended fields:

    http://processors.wiki.ti.com/index.php/Extending_data_structures_in_xDM#Constraints

    Someone more familiar with the codec would have to confirm this, but that's my guess at what's happening.

    Chris

  • 0 in reply to Chris Ring
    Prodigy 30 points

    Hi Chris,

    That is an excellent guess, and I had read that same section about incompatibility of pointers between ARM and DSP, etc.

    I had presumed that the TI designers of DSP code knew this (and much more) and figured out a way to translate the address - I've also seen examples of how you can grab a "server" module (RTSC config syntax) and translate DSP addresses into ARM side user address space, etc. I wondered if that concept was behind the non-documented use of "pContext" void pointer in the callback function.  Incidentally I did find a "pContext" field in the VISA_Obj structure but nothing ever sets it that I can find (it's NULL when I read it after codec instatiation).

    It would be awesome to get some insight from a TI expert that knows the origins of this callback function.

     

  • 0 in reply to Don Zimmerman
    TI__Prodigy 330 points

    Hello Zimmerman,

    pfNalUnitCallBack is DSP side function pointer and pContext is a void pointer kept for usage of preserving the context required for NAL unit call back. As Chris correctly pointed out, the problem you have faced is due to addressing DSP side pointer from ARM side. These two pointers are related to correct feeding of buffers to DSP codec in NAL unit callback. So some function which will be at DSP side, and do address translation for ARM pointer, buffer feeding to codec and context preserving is required on top of codec layer in order to correctly configure these pointers.

    Regards,

    Jaydeep