• State Answer Suggested
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 1749 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.

DM8168 Encoder channel 9...16 disturbed

Holger Eberhard102906
Genius 4570 points
Other Parts Discussed in Thread: TVP5158

Hi,
we use DM8168 in a custom design based on DVRRDK and UDWORKS demo.
We have a strange problem:
The upper 8 channels (9...16) bring the following problem:
Disturbances occur in recorded and streamed video (D1 720x576 encoded).
The disturbances are short strokes.
The attached snapshots show a black stroke at the top of the Image.
The first 8 channels (1...8) are OK.
No strokes can be seen on video Output for all 16 channels.
The strokes disapear if the first 8 cameras are disconnected.

Any ideas ?

BR Holger


  • 0
    TI__Guru* 80190 points
    Hello,

    FOr DVRRDK support check here:

    e2e.ti.com/.../426680

    You could search in the e2e for similar issue.

    BR
    Margarita
  • 0 in reply to Margarita Gashova
    Expert 2325 points

    Hi Holger,

                    Can you share the any sample stream where you had observed this issue. And also share the all the input parameter configurations set to reproduce this issue.Looking at the image, it looks like input to the Encoder may be going wrong (corruption pixels as black). 

    Regards

    Gajanan

  • 0 in reply to Gajanan Maske
    Genius 4570 points

    Hi Gajanan,

    Thank You for reply.

    I made some compare with older hardware. Our former hardware revision has not the problems.
    The difference is the used video decoder. In older parts TVP5158 is used. The new revision comes with TW2968.
    I have tested the same firmware on both revisions. (The decoder will detected automaticly).
    The older revision brings no encoder problems.
    So I think the main reason for the distrubances come form TW2968.

    BR Holger

  • 0 in reply to Holger Eberhard102906
    Genius 4570 points

    Hi,

    after some tests we found that the problem is not depending on decoder.

    Both hardware revisions with TW2968 and TVP5158 bring the distrubances.

    Currently we search why encoder channels 9...16 have the problem.

    BR Holger

  • 0 in reply to Holger Eberhard102906
    Genius 4570 points

    We made some tests with different DM8168 CPU revisions.
    I never got the problem with CPU revision 1.1, but CPU revision 2.1 brings the problems.
    Any issue with Revision 2.1 known ?

    BR Holger

  • 0 in reply to Holger Eberhard102906
    Expert 2325 points
    Hi Holger,

    There are no known issues with Rev 2.1.
    Did you observe this issue with single DM816x device or multiple DM816x devices ??


    Regards
    Gajanan
  • 0 in reply to Gajanan Maske
    Genius 4570 points

    Hi,

    we tested DM8168 CPU Rev. 2.1 ca. 15...20 pieces.

    I do not have so many parts with CPU Rev. 1.1 but I also got the problem at this CPU revision.

    But it takes more time till the problem occurs at revision 1.1.

    BR Holger

  • 0 in reply to Holger Eberhard102906
    Expert 2325 points

    Hi Holger,

                   By looking at the encoded bit-stream closely, I am suspecting the issue with input of the encoder (i.e before providing to encoder).

    The input pixels are corrupted or wrongly captured which is directly encoded by Encoder without suspecting any error.

                 To confirm this, Can you dump the input raw stream before providing to encoder & check the corruption. 

    Regards

    Gajanan

  • 0 in reply to Gajanan Maske
    Genius 4570 points

    Hi Gajanan,

    Thanks for Your answer.

    Yes, You are right, the corruption occurs at Encoding, but we can not see any corruption in the pre view video display output .

    This means the incomming captured content seems to be clear.

    We use multichannel_progressive_vcap_venc_vdec_vdis usecase from DVRRDK MCFW.

    The captured 16 channels are split into 2 parts of 8 channels.

    The second 8 Encoder channels get get the corruption.

    BR Holger

  • 0 in reply to Holger Eberhard102906
    Genius 4570 points

    Hi,
    If I change the order of the input of DEI_VIP_SC_D1_MERGE I can move the corruption from channel 9...16 to channel 1...8.
    So it seems that the problem occurs in the De-interlacer before.

  • 0 in reply to Holger Eberhard102906
    Genius 4570 points

    Ok, the corruption disappears after disabling tiler for deinterlacer:
      deiPrm[i].tilerEnable[DEI_LINK_OUT_QUE_VIP_SC] = FALSE;
    Does anybody have similar problem ?

    BR Holger