• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 466 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.

TSU Polyphase Interpolation does not work

Andriy Lysnevych
Intellectual 285 points

Hello,

In my transcoding program that runs on DSPC-8681 I use TSU component from latest MCSDK Video 2.1.0.3. In order to do that I link with both:

mcsdk_video_2_1_0_3/dsp/components/ti/mas/tsu/ce66/tsu_a.ae66

mcsdk_video_2_1_0_3/dsp/components/ti/mas/tsu/ce66/tsu_c.ae66

When I use Bicubic Interpolation for resizing decoded frames in YUV420P format (tsuConfig.mode = TSU_CUBIC_INTERP) everything works just fine.

When I use Polyphase Interpolation (tsuConfig.mode = TSU_POLYPHASE_INTER) output is green image with rubbish.

The questions are:

1) What interpolation is better by performance? (As I see from the source Polyphase Interpolation is manually optimized using assembler)

2) Why Polyphase interpolation does not work, while Bicubic one works perfectly?

I attached the code of my module for resizing (YuvResize.c) that shows how I use it. I use totally same code for both algorithms. The only difference is tsuConfig.mode that I set to TSU_CUBIC_INTERP or TSU_POLYPHASE_INTER.

  • 0
    TI__Mastermind 40580 points

    Hi Andriy, from which resolution to which resolution do you want to go?. About the performance question you are right polyphase algorithm is optimized and offers better performance.

    From MCSDK Video Functional Spec:

    3.1 Bi-Cubic Resizing

    Description: bi-cubic resizing algorithm is designed for general scaling operation without constraints.

    Performance: C version of implementation is available. The algorithm is not yet optimized for performance. 352x288 to 176x144, takes 3.5 MCPS/frame.

    3.2 Polyphase Resizing

    Description: Polyphase resizing algorithm is designed for general scaling operation. It uses poly-phase FIR filters with 32 phases and 4 taps, based on Lanczos2 kernel. Increased number of phases allows better approximation of requested output dimension (only number of filter coefficients is increased - no MIPS penalty for real-time execution).

    Performance:

    • 1280x720 to 1920x1080, takes 26.4 MCPS/frame (Filter (32 phase, 4 taps) design (once per input-output resolution pair) takes 0.71 MCPS)

    • 1920x1080 to 1280x720, takes 18.8 MCPS/frame (Filter (32 phase, 4 taps) design (once per input-output resolution pair) takes 0.62 MCPS)

    • 352x288 to 176x144, takes 0.65 MCPS/frame

    Paula

  • 0 in reply to Paula Carrillo
    Intellectual 285 points

    Hi Paula,

    I scale 704x576 to 4x smaller image (352x288)

    Are there any limitations on resolution for Polyphase Resizing?

  • 0 in reply to Andriy Lysnevych
    TI__Mastermind 40580 points

    Hi Andriy, Please see attached a CCS TSU test application that you can use as a base for testing. One thing that we think is missing in your YuvResize.c is the tsuContext.coeffHandle assignation (please see example test application). I also sometimes get green+garbage output if I don't initialize correctly the device. In order to initialize correctly the DSP please after connect the core do a system reset (Ctrl+shift+s) followed by loading your TSU.out program(Ctrl+Alt+L)  and loading the gel file (open gel file views -> evmc6678l.gel) and running the Global_Default_Setup (Scripts->EVMC6678L Init Functions->Global_Default_Setup)

    4466.1830.tsu.zip

    Note: Attached unit test has memcpy and EDMA options. You can define/undefine “USE_EDMA” to toggle between memcpy and EDMA.

    Thank you,

    Paula

  • 0 in reply to Paula Carrillo
    Intellectual 285 points

    Hi Paula,

    I found the problem - tsuContext.scratchHandle was set to NULL in my code, but should be initialized to address of scratch memory.

    I believe it will be good to check this and give an error if tsuContext.scratchHandle is NULL. Because currently TSU silently works with this NULL pointer and produces incorrect result.

    Also I noticed in TSU 2.2 is little different from my TSU 2.1 from latest MCSDK Video. It has:

    tsuContext.dataCopy
    tsuContext.dataWait

    I believe it is part of new MCSDK Video 2.2 that is not released yet. Am I right?

    Thanks,

    Andrey

  • 0 in reply to Andriy Lysnevych
    TI__Mastermind 40580 points

    Hi Andrey, thanks for your feedback, we will add in future releases cross check for memory handles.

    Paula