• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 443 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.

DVSDK 4, DM268, H264DEC parameter question

John Anderson
Genius 5240 points

I had a problem with H264 decode application on the DM368.  The details are in this thread....

http://e2e.ti.com/support/embedded/f/354/p/89168/309605.aspx#309605

Turned out that a significant issue was the default value of the frame_closedloop_flag location in the extended parameters IH264VDEC_Params.  When I switched it from the default of 0 to the value 1 my decoder started working.  The encoded stream is from another DM368 board running in H264 encode mode.

The question is... why did running in the default open mode break my app?

Also if anyone knows why I would be getting the VCIP errors shown in the other thread I would appreciate the help.

John A

  • 0
    TI__Expert 8465 points

    Hi,

    frame_closedloop_flag sets decoding mode, platinum decoder has two modes universal(frame_closedloop_flag = 0) and close loop mode(frame_closedloop_flag =1).

    Universal decoder can decode all .264 streams but closed has some limitations to achieve speed performance.

    Closed loop mode requires less memory compare to  universal decoder and it can decode 30frames per second of 1080p stream. I am not sure about VICP error, we have demo appliaction on single chip (platinum encoder + universal decoder) it runs fine. It works fine for error streams also.

  • 0 in reply to Veeranna Hanchinal
    Genius 5240 points

    Turns out that the problem with not using closedloop mode is that the decoder doesn't immediately release the video frames to the display thread.  There is another parameter called displayDelay that apparently holds back a number of decoded picture buffers based on that parameter.  This was halting my decode operation because I ran out of display buffers.

    Why one would do this is a total mystery to me.  Especially to do it and not document the behaviour.  It's hard to fathom why a designer would deside to squirrel away a bunch of buffers, especially ones this large and keep it a secret.  Not to mention the affect it has on the app designers timing plan.

    The VCIP errors are causing me serious issues.  For each frame decoded I get a string of errors that look like this....

    VICP Error: VICP_register() ioctl failed: -1
    VICP Error: VICP_wait() ioctl failed: -1
    VICP Error: VICP_wait() ioctl failed: -1
    VICP Error: VICP_wait() ioctl failed: -1
    VICP Error: VICP_wait() ioctl failed: -1
    VICP Error: VICP_wait() ioctl failed: -1
    VICP Error: VICP_wait() ioctl failed: -1
    VICP Error: VICP_wait() ioctl failed: -1
    VICP Error: VICP_wait() ioctl failed: -1
    VICP Error: VICP_wait() ioctl failed: -1
    VICP Error: VICP_wait() ioctl failed: -1

    Unfortunately the API is so abstracted it's nearly impossible to figure out where these errors are coming from.  The frames seem to be getting decoded ok even with the errors.

    John A

  • 0 in reply to John Anderson
    TI__Expert 8465 points

    Hi,

    below docement may be useful

    http://focus.tij.co.jp/jp/lit/an/sprab88/sprab88.pdf

    With closed closed loop decode mode also are you getting vicp errors?

    Are you using tool chain mentioned in release note? which version you are using? and ensure kernel module irqk.ko has been installed.