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

TI hardware renderer : not getting callback event for chroma conversion

sweta bhatt
Expert 2345 points

Hi,

We are using Rowboat android project for DM8168.  We are able to run decode-display application in this project.

As per our understanding, TI components in this Android release are taken from ezsdk_5_02.

We need to have V4L2 based video capture in Android, so we planned to port ezsdk_5_03_01_15 release components in Android.

We wanted to check whether there is any decode-display specific change in HDVPSS and HDVICP firmware between ezdk_5_02 and ezsdk_5_03 or not.

So we performed following experiments in ezsdk_5_02 and Android release.

1) Linux (ezsdk5_02) Take HDVPSS (V4L2) and HDVICP binaries from ezsdk_5_03 in ezsdk_5_02 decode-display application. Run decode-display application in Linux.

Result - decode_display works fine evenif we have new firmware in old ezSDK.

2) Android Take HDVPSS (V4L2) and HDVICP binaries from ezsdk_5_03 in Rowboat android (same as ezsdk_5_02) decode-display application. Run decode-display application in Android.

Result - decode-display doesn't work. We get empty buffer done and fill buffer done events for decoder but we don't get a single event of empty buffer done for chroma conversion routine.

Question -

1. Is there any specific change in HDVPSS/HDVICP firmware for chroma conversion/decoder ?

2. How can we debug this whether chroma conversion module is functional or not since we don't have source of HDVPSS and HDVICP firmware. The only way we know that issue is with chroma conversion is through callback events.

Thanks in advance,
Sweta

  • 0
    TI__Prodigy 500 points

    Hi,

    I am not sure this is a valid experiment. Because the component versions on host side (A8) and M3 side need to match - wrt omx/domx, syslink etc. Right now, in your test experiment, the situation is that you have newer components on M3 side and older component on A8 side. I am not sure whether even saMmapDisplay would work in this experiment.

    Its better to migrate to newer versions of components on A8 and then build (under rowboat-android\hardware\ti\ti81xx\)

    Regards,

    Naveen

  • 0 in reply to Naveen Gopalkrishna
    Expert 2345 points

    Hi Naveen,

    I understand that I should migrate to new components. I actually started with that. But after migration, my decode-display application stopped working.

    Hence, I removed all components and kept firmware binaries as the only change (since the same scenario worked fine in ezsdk_5_02 applications, which I use as reference for debugging).

    I have found the issue and fixed it to work with new firmware from ezsdk_5_03_01_15 release. omx of libstagefright has OMX spec violation, for which there is a work around in existing code. With new firmware changes on M3 side, this work around actually malfunctions the buffer pointer for scaler (VFPC) and I get ASSERTION for buffer alignment.

    Fix for the problem

    I think there is some change at decoder end to comply with this violation in ezsdk_5_03_01_15 release, which was not present in ezsdk_5_02 release (Rowboat android release as well).

    Following change needs to be done in Android Omx framework

    File - "frameworks/base/media/libstagefright/omx/OMX.cpp"

    OMX_ERRORTYPE OMX::OnFillBufferDone(
            node_id node, OMX_IN OMX_BUFFERHEADERTYPE *pBuffer) {
        LOGV("OnFillBufferDone buffer=%p", pBuffer);

    //SWETA: Comment this work around, not needed to ezsdk_5_03_01_15 onwards
    #if 0
        // Work-around issue where sometimes nFilledLen includes nOffset.  This
        // is an OMX spec violation.
        if (pBuffer->nOffset + pBuffer->nFilledLen > pBuffer->nAllocLen) {
            pBuffer->nFilledLen -= pBuffer->nOffset;
        }
    #endif

    File - "hardware/ti/ti81xx/libstagefrighthw/TIHardwareRenderer.cpp"

    status_t TIHardwareRenderer::init_csc(
                 size_t size, OMX_BUFFERHEADERTYPE *header)


    //SWETA: Comment below line and add this.

    //    mCscInputBufferSize    = header->nFilledLen + header->nOffset;
    mCscInputBufferSize     = header->nFilledLen;

    With above two fixes, Android should be able to work with new firmware binaries from ezsdk_5_03_01_15.

    Thanks,
    Sweta