• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 104 subscribers
  • Views 1027 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

SW-OSD problem with YUV frames at A8

Jay Amin
Prodigy 155 points

Hi All,

We are using IPNC_RDK 3.5 for DM8127 processor.
We are trying a use-case as given below.

USECASE-1 :

In this usecase, We are facing problem with YUV frames at A8. YUV frames of YUV CH1 comes with an OSD of STREAM CH0 and STREAM CH1, and YUV frames of YUV CH0 comes with an OSD of  STREAM CH0.
So, here both YUV Channels comes with an OSD without applying on it, YUV CH1 with two OSD and YUV CH0 with single OSD.

I have attached the snapshots for both YUV channels.


If we use-case(use-case 2) as given below, then everything is working fine. Both YUV channels don't have any OSD on them.
In this use-case we have connected DUP 1 next to the DEI link and FD link next to the SCALAR link.

USECASE - 2:

In both use-case, we are using DEI as a scalar.

We don't understand why this is happening?.  Kindly help us to resolve the problem.
Your answers will be helpful to us.

YUV_SNAPSHOTS_USECASE1.tar.gz
  • 0
    TI__Guru**** 170625 points

    Hello,

    I will notify our IPNC RDK team for help.

    Regards,
    Pavel

  • 0
    Intellectual 650 points

    Because one channel to SWOSD  is directly from the original frames, and the other channel to SWOSD  is  from the frame that is scaled from the  original frames.

    The adress of  inputting frames processed by SWOSD are same as the adress of outputting frames.

    If the original frames are processed by scaler and SWOSD, there would be a satiuation that the  original frames are processed by SWOSD firstly, and then transferred to scaler, because 'the adress of  inputting frames processed by SWOSD are same as the adress of outputting frames'. Then, the frames processed by the scaler are putting into the SWOSD again, the resolution of the scaled frames is differrent from the original frames. So you can get double OSD. If the resolution of of the scaled frames is same as the origin frames, you can get only one OSD. But you have done SWOSD for two times.

    If you want to solve the problem, you should set signals to do scaling firstly, and then do SWOSD.

    PS:  the function of Duplink is only copying the frame parameters structure,  not copying the frames.

  • 0 in reply to yuxi
    Prodigy 155 points

    Hi kun He,

    Thanks for your valuable reply.
    Here if we use use-case 2, then we don't find any issue like this.

    We have also tried to sync SWOSD link with scalar link using semaphore. Still we have same results.
    Is there any other way to set signal for SWOSD link ?

  • 0 in reply to Jay Amin
    TI__Expert 8920 points

    Hi Jay,

    We have modified DUP link so that it forwards the frames on a configured queue only when all the other queues have returned the frames back to DUP link. This feature is called 'Dup Delay'.

    From A8 side you can call the API 'Vsys_setDupDelayPrm(dupId,0); ' to configure queue 0 as the queue on which the frames will be forwarded only when all the other queues like 1,2,3 have returned back the frames.

    Using this feature in your use case you can avoid SWOSD issue as the frames will be forwarded to the SWOSD link only after they are scaled by the scalar link.

    Of course this feature will introduce some latency in the chain.

    If latency is not acceptable then you have to go for frame copy in the SWOSD link.

    I have attached the code for Dup Delay feature and also frame copy in SWOSD link.

    Pl. refer to the code under 'COPY_FRAMES' compile flag in swosdLink_tsk.c file.

    regards,

    Anand7317.Dup_delay_patch.7z

  • 0 in reply to Anand Kulkarni71405
    Genius 3925 points

    Anand:

    Do you have a patch for RDK3.8? 

  • 0 in reply to Hongfeng Wang
    TI__Expert 8920 points

    Hi Wang,

    The feature is already part of IPNC RDK ver 3.8.

    regards,

    Anand

  • 0 in reply to Anand Kulkarni71405
    Genius 3925 points

    Anand:

    I am using RDK3.8 now, I dont' see the patch applied.

    Take swoskLink_tsk.c for example, I dont see COPY_FRAMES defined or used anywhere.

    Regards,

    Hongfeng Wang

  • 0 in reply to Hongfeng Wang
    TI__Expert 8920 points

    Hi Wang,

    Oh yes, IPNC RDK has only DUP delay feature.

    The frame copy in SWOSD is not there.I will provide you the patch on Monday.

    regards,

    Anand

  • 0 in reply to Jay Amin
    Intellectual 650 points

    I'm sorry for replying so lately.  I'm so busy that I do not log in for long time.

    The use case 2 is OK , Maybe there are  some locks in the DEI thread modules, you could read the codes in details.

    If you want to solve the problem for ever, the best way is to complete a new link of copying frames by yourself. In my use case,  the SWOSD of every channel followed by DUP link is not the same, I add the new link of copying frames to complete the function.