cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Adventurer
Adventurer
843 Views
Registered: ‎06-22-2017

DP1.4 rxss receive YCbCr422 color format

HI,

I use DP1.4 rxss as sink to receive video stream from source,
the block design refers to dp1.4 example as following,
and in vpss, I convert color format into RGB.

 

DP1.4 rxss --> frame crc --> vid_remap --> vpss --> vdma --> memory

 

Our flow is :

1. output RGB color bar from the source

2. write rx receiving frames into memory

3. read frames from memory and save as bmp file

 

when color format is RGB or YCbCr444, the bmp file shows all the pixels are correct

(because the bmp file looks exactly the same as we output from source)

cap1.PNG

 

but when it's YCbCr422, apparently most of the pixels are wrong.

cap2.PNG

 

I also use ILA to check raw data, it's not quite the same in every line since dp rxss video streaming.

I'm not sure what cause this problem, please help. thanks

cap3.PNG

Tags (1)
0 Kudos
Reply
16 Replies
Xilinx Employee
Xilinx Employee
773 Views
Registered: ‎03-07-2018

Hi @furball 

We tried to reproduce this issue with QD780E and Samsung U28E590D monitor with KCU105 board based DP14 passthrough example design. 

We see color change when YUV422 video data type is selected from QD780E graphics source. We have reported this issue to development team. 

YUV444 input:

YUV444 from SourceYUV444 from Source

YUV422 from source:

YUV422 from SourceYUV422 from Source

Can you please let me know you video source and sink details? 

Which Vivado version and Xilinx FPGA board you are using?

Run following test and share UART log with us:

  1. Run passthrough example on board and set video source to RGB444 with supported resolution of your monitor (for example resolution 3840x2160_60_P).
  2. Capture MSA register dump and VPHY status in UART console
  3. Change to other resolution of graphics card (1920x1080_60_P)
  4. Capture MSA register dump and VPHY status in UART console
  5. Change resolution of graphics card to 3840x2160_60_P with video source set to YUV422
  6. Capture MSA register dump and VPHY status in UART console
  7. Change resolution of graphics card to 1920x1080_60_P with video source set to YUV422
  8. Capture MSA register dump and VPHY status in UART console
  9. Go back main menu of UART and switch to TX only mode
  10. Capture MSA register dump and VPHY status in UART console
  11. Change Video type in Video data type in TX only to YUV 422
  12. Capture MSA register dump and VPHY status in UART console

Please capture snapshot of your observation throughout the test.

 

Regards,
Bhushan

-------------------------------------------------------------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
-------------------------------------------------------------------------------------------------------------------------------------------------
Adventurer
Adventurer
734 Views
Registered: ‎06-22-2017

Hi @bpatil ,

Following are some information:

- vivado 2020.1

- dp rxss version is v2.1(Rev. 2)

- device part is xczu6eg-ffvc900-2-i  (we implement dp functions in Microblaze)

- sink: NV P3200, source: dell UP3216Q monitor

 

Attach log for six different cases for your reference.

But throughout the test, I think it's because of the issue, when in pass-through mode, YCbCr422 format, the monitor shows nothing.

 

May I know when will this issue be fixed?

 

 

 

 

0 Kudos
Reply
Xilinx Employee
Xilinx Employee
674 Views
Registered: ‎03-07-2018

Hi @furball 

Our development team is working on this issue. It will take some time resolve this issue.

I will keep you updated on progress.

 

Regards,
Bhushan

-------------------------------------------------------------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
-------------------------------------------------------------------------------------------------------------------------------------------------
Explorer
Explorer
654 Views
Registered: ‎05-04-2014

Hi @bpatil ,

Is it possible to fix this issue on vivado 2020.2 ?

 

 

Thanks

Sitting

0 Kudos
Reply
Xilinx Employee
Xilinx Employee
624 Views
Registered: ‎03-07-2018

Hi @sitting 

I am not sure, if this issue gets fixed in 2020.2. Possibility seems to be lesser, as currently 2020.2 is in release phase. 

In our earlier tests, we haven't observed this issue with ZCU102 based example design. So, for now you can refer to ZCU102 based example design for your design. 

Regards,
Bhushan

-------------------------------------------------------------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
-------------------------------------------------------------------------------------------------------------------------------------------------
0 Kudos
Reply
Adventurer
Adventurer
596 Views
Registered: ‎06-22-2017

Hi @bpatil ,

I tried to run pass-through example again with both ZCU102 and KCU105 with a laptop and Dell P2317H monitor, it’s indeed that ZCU102 has no problem with 422, however, I can’t reproduce the color bias situation as you did with KCU105, instead, it shows nothing on the monitor. I’m wondering if it depends on different sink and source?

7DAAD4C3-F669-4C28-B197-03B6CC56A1EE.jpeg

0 Kudos
Reply
Xilinx Employee
Xilinx Employee
569 Views
Registered: ‎03-07-2018

Hi @furball 

Which video source you are using?

I also suspect KCU105 DP14 example design issue with YUV422 data type changes with Video source. We have tested it multiple sources and results were different. We have also observed blank display for one of the tested video source, while with Nvidia RTX4000 and AMD Radeon graphics source we observed blurry outline output. 

Regards,
Bhushan

-------------------------------------------------------------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
-------------------------------------------------------------------------------------------------------------------------------------------------
0 Kudos
Reply
Adventurer
Adventurer
551 Views
Registered: ‎06-22-2017

Hi @bpatil ,

the source I'm using are NV Quadro P3200 and NV Quadro RTX4000, both blank display.

0 Kudos
Reply
Adventurer
Adventurer
528 Views
Registered: ‎06-22-2017

Hi @bpatil ,

If this issue cannot be fixed in 2020.2, any patch will be released? Do you know about when?

0 Kudos
Reply
Adventurer
Adventurer
436 Views
Registered: ‎06-22-2017

HI @bpatil ,

Is there any update on this case? Is it been fixed now?

0 Kudos
Reply
Xilinx Employee
Xilinx Employee
421 Views
Registered: ‎03-07-2018

Hi @furball 

Not yet. I will certainly update you once this issue resolved. 

As I mentioned earlier, we have reported this issue to development team already. Development team is working on this issue but there is no significant progress for now (getting delayed due to 2020.2 release as well as some other high priority task with development team). ZCU102 example design working well with YUV422 data type shows, this signifies there is no issue with Xilinx DisplayPort IP's. We suspect there is issue with video pipeline data handling. Moreover, issue with YUV422 data type for  DisplayPort 1.4 IP passthrough example design changes with change in Video source; this makes it more difficult to debug.

Right now, I believe it will take while to fix this issue 3-4 weeks or more.  Till that time, we recommend to follow ZCU102 DisplayPort 1.4 example design.

 

Regards,
Bhushan

-------------------------------------------------------------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
-------------------------------------------------------------------------------------------------------------------------------------------------
0 Kudos
Reply
Adventurer
Adventurer
399 Views
Registered: ‎06-22-2017

Ok thanks

0 Kudos
Reply
Xilinx Employee
Xilinx Employee
150 Views
Registered: ‎03-07-2018

Hi @furball 

The attached kcu105_pt_src.zip folder contains updated source files for kcu105 passthrough 2020.1 application.
The application is updated for 422 component format.

Earlier the value of component format being passed for 422 was incorrect which lead to color shift being visible. Also retraining support is added if color component format is changed.

Please note that there is one case below where memory write to a register will be needed >> It’s been observed that for 8k30 422, Nvidia trains our Rx at 5.4x4 and thus our Tx also trains either at 5.4x4(mostly) or 8.1x4. In such case the video on the sink would be corrupted. This is due to linereset issue on our Rx. To resolve this please set the Rx linereset disable register using memory write. For eg: mwr -force 0xXXXXXXXX(Rx base address + XDP_RX_LINE_RESET_DISABLE (0x008) reg address) 0x1.
This issue is known and  would be resolved for 2021.1 release.

Kindly check example design with attached application code.

Regards,
Bhushan

-------------------------------------------------------------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
-------------------------------------------------------------------------------------------------------------------------------------------------
0 Kudos
Reply
Adventurer
Adventurer
118 Views
Registered: ‎06-22-2017

Thanks. I'll try it.

0 Kudos
Reply
Adventurer
Adventurer
69 Views
Registered: ‎06-22-2017

Hi @bpatil ,

After modifying source code refer to your attached files, pass-through 422 function works fine, but it only solve the pass-though problem.
In our design, we also transfer video streaming into vpss to convert it to RGB, and the problem is still there :
when we convert 422 to RGB, the output RGB streaming looks abnormal.

DP1.4 rxss --> frame crc --> vid_remap ----input streaming----> vpss ----output streaming----> vdma --> memory

(1) when input streaming format is RGB or YCbCr444, after convert to RGB by vpss, all data looks fine
cap1.PNG

(2) when input streaming format is YCbCr422, after convert to RGB by vpss, it fails
cap2.PNG

Any idea what would cause this? How to check if vpss convert streaming correctly?
Attached our vpss source code

0 Kudos
Reply
Xilinx Employee
Xilinx Employee
4 Views
Registered: ‎03-07-2018

@furball 

I need to check on it. Please spare me some time.

Regards,
Bhushan

-------------------------------------------------------------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
-------------------------------------------------------------------------------------------------------------------------------------------------
0 Kudos
Reply