• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 100 subscribers
  • Views 1090 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.

Dual H264 decode, 1080p60, DM8168

_Ralph_
Guru 10685 points

This thread is a sort of continuation and rebirth of this one which is unresolved as of now:

http://e2e.ti.com/support/dsp/integra_dsparm/f/625/p/121270/449518.aspx

I used the decode_display demo that was provided here along with some corrections provided here and here to create a working decode and display application for a single video using a single decoder at 1080p60.

I then converted the application to work with 2 separate videos and decode them simultaneously by:

  • - fixing a bug that I found (change memset(pAppDataPtr, 0x00, sizeof(IL_Client)); to memset(pAppDataPtr, 0x00, sizeof(IL_Client)); in IL_ClientInit() )
  • - altering IL_ClientSetDisplayParams() to set nDrvInstID differently so that the first video could be outputted to HDMI and the second to analogue DAC.
  • - using 2 separate instances of an IL_Client struct - one for each video
  • - splitting the Decode_Display_Example() function into 2 parts. The first part is run sequentially for each video as a normal unthreaded function in order to set up the OMX components, connect them, and set them to IDLE state. The second part is a thread (one thread is run concurrently for each video clip) which changes the state of each set of components to execute and then sleeps for 30 seconds in order to allow each video to be decoded and displayed on their respective video displays.

In practise I have never had both videos being decoded in parallel, let alone managed to progress both sets of components beyond the IDLE state.

Here is a summary of what happened when I tested the new application (I've just checked this again on my EVM).

  1. The first time the non-threaded "normal" function is called (for the first video clip) completes fine with its final step of setting the display state to IDLE. The second time it's called (for the second video clip) hangs at the first ever semp_pend(pAppData->decILComp->done_sem)call just before the "state IDLE" printf.
  2. Forcefully slowing the execution of the function down with sleep() statements causes the non-threaded function to fail (with the second video) at an earlier stage than above: after the first ever call of the OMX_AllocateBuffer(). It hangs after the first call and the second call blocks and never completes.
  3. This suggests one of the OMX framework threads operating in the background (presumably from setting up the first video OMX chain) is causing an issue.
  4. I have tried using gdbserver on the target with gdb on the host to debug the application however I find it hangs in the platform_init() call and doesn't return control to gdb. (I edited ti-ezsdk_dm816x-evm_5_01_01_80\omx_05_01_01_80\packages\makerules\rules_a8_extend.mk to change the "-O2" to "-g" and rebuilt the OMX framework).

Hope this clears up the current state of where I've got to with the dual decode display application. Any help obviously would be extremely gratefully appreciated.

Thanks,
Ralph

  • 0
    TI__Genius 9510 points

     

    1) have you tried creating a separate pAppData instance for each decode channel?

    4) Do you have access the a JTAG emulator?  If so, then it would be possible to debug without the need for gdbserver.  Otherwise, I would need to reproduce to understand why this is occuring. 

  • 0 in reply to Marcus Cooksey
    Guru 10685 points

    1) Yes, that's what I mean when I say "using 2 separate instances of an IL_Client struct - one for each video"

    4) Yes I have the XDS 560v2. I thought that was best used for debugging the kernel itself? How would I use it to debug a single process?

    By the way, I forgot to mention that the other bug fix I made was to remove the Omx_init() call from the main function as this initialisation is already done within  platform_init().

    Thanks,

    Ralph

  • 0 in reply to _Ralph_
    TI__Genius 9510 points

    4) I was mistaken at when platform_init() was called and you're correct kernel level debugging should be used with XDS 560v2. 

    I've discussed this internal and we experienced similar issues and attempting to work throught it.  We're not sure if the underlining problem is related to the software tools which we plan to have addressed in the SDK 5.02 release in mid-August time frame.

  • 0 in reply to Marcus Cooksey
    Guru 10685 points

    Hi Marcus,

    that is indeed reassuring to know.

    Best regards,

    Ralph

  • 0 in reply to Marcus Cooksey
    Genius 3055 points

    Hi Marcus, what about the EZSDK 5.02? Maybe until mid-September?

    Is there anywhere a changes list which let us know, which changes at best circumstances might become available within that and the next versions?

    Just for vague planning...

    Thanks,
    Joern.

  • 0 in reply to Joern
    Guru 10685 points

    Hello again,

    the new EZSDK (version 5.02.01.59) is out at last. Does this one support dual parallel decode? Of course I could go about rewriting the single stream application again, but I'd prefer to get a "yes" or "no" answer first so I don't waste any time. It's hard to keep up with a moving target with a new EZSDK coming out every month or two.

    Thanks,
    Ralph

  • 0 in reply to _Ralph_
    TI__Expert 6535 points

    Hi Ralph,

    This SDK  supports dual decode . You could try your earlier IL client for Dual decode. It should be functional.

    Regards

    Vimal

  • 0 in reply to Vimal Jain
    Guru 10685 points

    Great, thanks for this information.

    Ralph

  • 0 in reply to _Ralph_
    Guru 10685 points

    I'm happy to say that I've got dual decode working now with one output on the HDMI and one on RGB DAC (component). The CPU usage is a bit high to be honest at 50-60% but hopefully this will just about allow me to run some other applications at the same time.

    I'd like to test triple decode but clearly there are only 2 HD outputs on the board. Is it possible to get the CTRL-DC component to switch its port inputs on the fly? Ideally I'd switch between different clips every second then I could prove that triple decoding was working by showing one video decode stream on the HDMI, and the other 2 would time-share the RGB DAC output. When one stream was not outputting to the RGB DAC, it would simply discard frames.

    With OpenMAX would I have to bring the components to IDLE in order to share one of the display outputs on the EVM or is there another way without having to bring down the entire chain of OMX components? Bringing the chain of OMX components down and up seems like it might involve lots of overhead.

    Thanks,
    Ralph

  • 0 in reply to _Ralph_
    Guru 10685 points

    Is it possible to get the CTRL-DC component to switch its port inputs on the fly?

  • 0 in reply to _Ralph_
    TI__Expert 6535 points

    Hi,

    CTRL-DC componnet does not have ports. probbaly you meant changing the displays on the fly ?

    For your use case, may be you can have X buffer allocated from componnet A, Y buffers allocated from componnet B, and do USE_Buffer call for X+Y buffers on display component, and have intelelligence built in IL client to provide those buffers to Display component selectively.

    Regards

    Vimal