UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Participant miguelcosta94
Participant
2,186 Views
Registered: ‎11-14-2018

Video Test Pattern Generator issue

Jump to solution

Hi,

I am using Vivado 2018.2 to build a project where the Video Test Pattern Generator (VTPG) creates some frames to be stored in the DDR3 Memory of Zybo board, by means of an AXI Video DMA block connected to the Zybo's Processing System. After a frame being stored on the memory, I write the content of the respective memory block to an SD card. However, I'm experiencing some problems to get the project working properly. Despite configuring the VTPG to generate a frame with a solid blue color in the background, the FFMPEG program shows the following strange green frame when reading the data stored in the SD card. Am I missing something?

Best regards

Capturar.PNG

0 Kudos
1 Solution

Accepted Solutions
Participant miguelcosta94
Participant
1,413 Views
Registered: ‎11-14-2018

Re: Video Test Pattern Generator issue

Jump to solution

Hi @samk,

I already solved the problem. The VDMA was always writing to the expected memory addresses. However, as I haven't configured the SCU to maintain the coherency between data cache and RAM, I always get unexpected data when performing a read from those memory addresses. In this context, there are two ways to solve the problem:

  1. Configure the SCU;
  2. Invalidate the data cache lines associated with the memory addresses used by the VDMA.

I must also mention again that YUV422 (8 bits) frames generated by the VTPG can only be reproduced by the FFMPEG if the -pix_fmt option is configured to yuyv422, as @hokim suggested. This comes as a consequence of the pixel arrangement performed by the VTPG, which follows an interleaved approach.

 

23 Replies
Moderator
Moderator
2,122 Views
Registered: ‎10-04-2017

Re: Video Test Pattern Generator issue

Jump to solution

Hi @miguelcosta94,

 

I believe FFMPEG can use many different pixel formats. If the format of the pixels generated by the TPG does not match what the FFMPEG is expecting, you will not see the correct color.

 

https://www.ffmpeg.org/doxygen/0.11/group__lavc__misc__pixfmt.html

-Sam

Don't forget to reply, kudo, and accept as solution.

Xilinx Video Design Hub
Participant miguelcosta94
Participant
2,111 Views
Registered: ‎11-14-2018

Re: Video Test Pattern Generator issue

Jump to solution

I'm generating YUV422 frames with 8 bits per component. The frame's size is set up to 640x480. With this configuration, it's expected that each pixel takes 2 bytes of memory, being a frame comprised in 600KB. I'm using the following command to reproduce the frame generated by VTPG: "ffplay -f rawvideo -pixel_format yuv422p -video_size 640x480 -i FILE.bin". From the panoply of pixel formats available, I think that I'm selecting the right one.Screenshot_2.png

0 Kudos
Scholar watari
Scholar
2,100 Views
Registered: ‎06-16-2013

Re: Video Test Pattern Generator issue

Jump to solution

Hi @miguelcosta94

 

Would you make sure the followings ?

 

- Video format at VTG (I guess it's RGB)

- Option (Video format) on ffmpeg (I guess it's YUV422)

 

I'm not sure, in this case, you should set same video format.

Would you try it ?

 

Best regards,

Participant miguelcosta94
Participant
2,070 Views
Registered: ‎11-14-2018

Re: Video Test Pattern Generator issue

Jump to solution

I configured the color_format register of VTPG with the value 2, which corresponds to YUV 422 video format, according to the documentation. This is my hardware configuration:

Screenshot_5.png

 

 

0 Kudos
Moderator
Moderator
2,052 Views
Registered: ‎10-04-2017

Re: Video Test Pattern Generator issue

Jump to solution

HI @miguelcosta94,

 

Another part of this equation is to check the VDMA. All of the IP in the video stream needs to be operating with the correct colorspace/depth. If not, it is possible that the pixels will become corrupted.

In addition to the colorspace/depth, you will need to check that the VDMA is writing to the correct location and that the data on the SD card is correct. If you change the color from blue to another color, does the image change? (Colorbars is a popular option from the VTPG for validating video frames)

 

-Sam

Don't forget to reply, kudo, and accept as solution.

Xilinx Video Design Hub
0 Kudos
Participant miguelcosta94
Participant
2,038 Views
Registered: ‎11-14-2018

Re: Video Test Pattern Generator issue

Jump to solution

The hardware configuration of the VDMA is depicted in the figure below. To configure the register space of this IP Core, I used the functions given by the Board Support Package. Firstly, I called the function XAxiVdma_SetFrmStore() to set the frame store of the VDMA write channel to the number of frame buffers given by the hardware. Secondly, I called the function XAxiVdma_SetFrameCounter() to set the frame counter of the S2MM control register to only 1 frame. Thirdly, I used the function XAxiVdma_DmaConfig() to prepare the VDMA to handle frames with a vertical size of 480 lines and a horizontal size of 640*2 bytes (YUV422 with 8 bits per color component leads to a pixel size of 2 bytes). The stride was also set to 640*2 bytes. Furthermore, I enabled the circular buffer strategy and turned off the gen-lock mechanism. The second figure below provides more details on this configuration.

The VDMA is writing something to the correct memory addresses and this data is correctly written to the SD card. However, when I open the binary file written to the SD card with the FFMPEG library, I notice that the frame does not correspond with the one I was expecting.

 

Screenshot_7.pngScreenshot_8.png

0 Kudos
Explorer
Explorer
2,023 Views
Registered: ‎10-21-2015

Re: Video Test Pattern Generator issue

Jump to solution
Participant miguelcosta94
Participant
1,983 Views
Registered: ‎11-14-2018

Re: Video Test Pattern Generator issue

Jump to solution

Hi 

I reconfigured the VTPG to generate frames with tartan color bars in the background. I made a batch script to iterate over the available color formats supported by the ffmpeg library, taking a screenshot of the frame stored in the SD card interpreted according to the current color format. The output for the color format yuv422p is shown in the first figure, while the output for the yuyv422 format is shown in the second one.yuv422p.pngyuv422pyuyv422.jpgyuyv422

0 Kudos
Participant miguelcosta94
Participant
1,973 Views
Registered: ‎11-14-2018

Re: Video Test Pattern Generator issue

Jump to solution

By checking the S2MM status register I spotted that the VDMA is issuing an error. In fact, the bit EOLLateErr (End of Line Late Error) is asserted. According to the documentation, this error occurs if the incoming line size is greater than the programmed hsize value. However, I think that I configured the VDMA hsize correctly:

  • The VTPG is generating 640 columns, being each column associated with a pixel of 2 bytes (YUV422);
  • The hsize of VDMA was configured to 640*2 bytes.

Am I missing something?

0 Kudos
Moderator
Moderator
1,945 Views
Registered: ‎10-04-2017

Re: Video Test Pattern Generator issue

Jump to solution

Hi @miguelcosta94,

 

It looks like there may be 2 issues here. 1 with the VDMA and one with the colorspace.

 

Let's look at the colorspace first. Based on your latest pictures it looks like your yuv ordering is still off. Can you attach your bin file so that we can take a look at the formatting?

Also, it looks like in the ffmpeg file you are selecting an option with 3 components. Is ther an option with 2 components?

 

Thanks,

Sam

Don't forget to reply, kudo, and accept as solution.

Xilinx Video Design Hub
0 Kudos
Participant miguelcosta94
Participant
1,906 Views
Registered: ‎11-14-2018

Re: Video Test Pattern Generator issue

Jump to solution

I almost solved the problem...

The color format of the video test pattern generator can only be configured in the register space, after the VTPG being placed on the FPGA. At the time of VTPG placement, the IP Core assumes the RGB format as default. This means that the data width of the AXI channel is configured for the RGB color format, which is 2 bytes larger than it was supposed to be when using the YUV422 with 8 bits per component. This leads the VTPG to generate data with padding. However, instead of inserting a bunch of 0's when padding, the VTPG repeats the least representative byte. That's why the frame looked so strange... Besides that, the correct color format to use in the FFMPEG is the YUYV422, as @hokim suggested.

However, after cleaning the padding I'm still facing a problem: the VDMA does not write to some memory addresses located between the beginning and the end of each slot in the buffer. The unwritten memory addresses vary every time I re-launch the debug. This is how a frame with a solid green background looks like at this moment...

yuyv422.jpg

0 Kudos
Moderator
Moderator
1,890 Views
Registered: ‎10-04-2017

Re: Video Test Pattern Generator issue

Jump to solution

Hi @miguelcosta94,

 

How are you removing the padding? (UG934 is very helpful for showing bus data representation)

 

"VDMA does not write to some memory addresses":

This should be reported as an error in the S2MM_VDMASR Register. Do you have this register unmasked and are there any errors reported?

Are the same memory addresses every frame, or is it different for every frame?

 

Alternatively, is it possible that this memory is being used by the processor for something else or that the function pulling this memory from the DDR to the SD card may be not pulling the memory correctly?

-Sam

Don't forget to reply, kudo, and accept as solution.

Xilinx Video Design Hub
Participant miguelcosta94
Participant
1,868 Views
Registered: ‎11-14-2018

Re: Video Test Pattern Generator issue

Jump to solution

Hi @samk,

I checked the S2MM_VDMASR register. It does not report any error. The buffer associated with the VDMA has 3 slots and I configured the VDMA to stop after receiving 1 frame. I think this eliminates errors associated with reading and writing to the same memory address at the same time. The function writing to the SD card is working properly. I noticed that the VDMA randomly skips some memory addresses by analyzing the respective memory block at debug time.

0 Kudos
Moderator
Moderator
1,858 Views
Registered: ‎10-04-2017

Re: Video Test Pattern Generator issue

Jump to solution

Hi @miguelcosta94,

Only sending 1 frame is good information. Also noting that you can see that the VDMA is skipping addresses is another. Where are you probing during debug time? Are you probing directly on the AXI bus output of the VDMA? Can you send this wave file or an image of this?

The logic for addresses in the VDMA is simple and should only increment addresses. 

Is there a relationship to the addresses that are skipped? Are they every X addresses?

 

Thanks,

Sam

Don't forget to reply, kudo, and accept as solution.

Xilinx Video Design Hub
0 Kudos
Participant miguelcosta94
Participant
1,853 Views
Registered: ‎11-14-2018

Re: Video Test Pattern Generator issue

Jump to solution

I'm debugging through Xilinx SDK. While debugging, I'm observing the memory addresses the VDMA is writing on by using a Xilinx SDK memory monitor. I'm struggling to find a relationship between the addresses that are skipped because they are not always the same, and the length of addresses skipped also varies in each debugging session. Furthermore, the length of address skipping is not maintained in every address skip event that occurs during a given debug session. The figures below show a given memory block that the VDMA is writing on. The address under a blue background is the start address. This is for a frame with a solid green background.

Screenshot_2.pngScreenshot_3.png.

0 Kudos
Moderator
Moderator
1,844 Views
Registered: ‎10-04-2017

Re: Video Test Pattern Generator issue

Jump to solution

Hi @miguelcosta94,

 

I'm debugging through Xilinx SDK. While debugging, I'm observing the memory addresses the VDMA is writing on by using a Xilinx SDK memory monitor

I am not sure that this is the best debug method for this issue, can you explain a little further:

What address you are observing and what is at that address? Is this the DDR memory? What part of the frame transfer are you observing?

I am wondering what happens if you are trying to access the memory at the same time you are writing to the memory.  I am not sure if that will cause contention for the same resources. 

The best way to debug this is to put an ILA on the AXI bus directly after the VDMA and trigger as it starts to write to the memory.

Can you post a picture of your block design with the VDMA?

 

Thanks,

Sam

Don't forget to reply, kudo, and accept as solution.

Xilinx Video Design Hub
0 Kudos
Participant miguelcosta94
Participant
1,839 Views
Registered: ‎11-14-2018

Re: Video Test Pattern Generator issue

Jump to solution

What address you are observing and what is at that address? Is this the DDR memory? What part of the frame transfer are you observing?

Yes, this is the DDR memory. The memory block I've shown corresponds to the beginning of the frame.

I am wondering what happens if you are trying to access the memory at the same time you are writing to the memory.  I am not sure if that will cause contention for the same resources. 

I ran the program with the XDSK memory monitor closed and the problem remained.

Can you post a picture of your block design with the VDMA?

The figure below shows my block design. It appears that when I increase the write burst of the VDMA, the number of address skip events increases.

 

Screenshot_4.png

0 Kudos
Moderator
Moderator
1,800 Views
Registered: ‎10-04-2017

Re: Video Test Pattern Generator issue

Jump to solution

Hi Miguel,

 

This may be an issue with the AXI SmartConnect, in this case, the SmartConnect is not necessary because you only have one interface. Can you remove the SmartConnect and put an ILA on the M_SXI_S2MM interface of the VDMA? 

 

Thanks,

Sam

 

Don't forget to reply, kudo, and accept as solution.

Xilinx Video Design Hub
0 Kudos
Participant miguelcosta94
Participant
1,792 Views
Registered: ‎11-14-2018

Re: Video Test Pattern Generator issue

Jump to solution

Hi @samk

I've spotted a problem in my code. I was writing to some memory addresses of the VDMA buffer in a dummy function I created for debugging purposes. After solving that problem, I noticed that the memory addresses skipped are always the same for a given buffer's slot. I've reconfigured the register space of the VDMA to receive up to 10 frames, which are stored in a circular buffer with three slots. After analyzing the last three frames produced, I concluded that the only frame that looks like it should is the frame stored in the second slot. The frames stored in slots one and three always exhibit some strange pixels. This strange pattern is always the same for every frame stored in these two slots. The first three figures below show the frame stored in each buffer's slot. The last two pictures compare the content of the second slot with the content of the first and third slot (the padding was removed).

frame_Slot1.jpgslot1frame_Slot2.jpgslot2frame_Slot3.jpgslot3

diff_frameSlot2-1(1).pngslot 2 vs slot 1 (begining)diff_frameSlot2-1(2).pngslot 2 vs slot 1 (end)diff_frameSlot2-3.pngslot 2 vs slot 3

 

 

0 Kudos
Moderator
Moderator
1,772 Views
Registered: ‎10-04-2017

Re: Video Test Pattern Generator issue

Jump to solution

Hi @miguelcosta94,

 

Good job finding the issue in your code. I will consider the first issue solved.

 

Moving on to this second issue, we should go over the default checks, some are repeats from earlier that need to be confirmed again.

 

  1. What order are you starting the stream? Is the TPG started after the VDMA?
  2. Are your addresses for the buffers correct, and within the correct memory space?
    1. If you switch the address for frame 1 and frame 2 does this change anything?
  3. Do you receive any interrupts from the status registers?
  4. Have you verified your "padding" in ug 934?

 

Thanks,

Sam

Don't forget to reply, kudo, and accept as solution.

Xilinx Video Design Hub
0 Kudos
Participant miguelcosta94
Participant
1,760 Views
Registered: ‎11-14-2018

Re: Video Test Pattern Generator issue

Jump to solution

Hi @samk

1. What order are you starting the stream? Is the TPG started after the VDMA?

Yes, I start the TPG after the VDMA.

2. Are your addresses for the buffers correct, and within the correct memory space?

In an attempt to solve my problem, I reconfigured the hardware to allow unaligned transfers. However, the VDMA still does not write to the addresses I want. If I want to write to the address 0x60000000, it will write to the address 0x60000080. But if I want to write to the address 0x60000080, it will write to this address. If I want to write to the address 0x60000088, it will write to the address 0x60000100. I really don't know why this is happening. This is the major problem I'm facing right now. In the figures below you can find my current configuration of the VDMA.

3. Do you receive any interrupts from the status registers?

Only the interrupt from the frame counter, but I enabled it.

4. Have you verified your "padding" in ug 934?

I think the padding problems are already solved. As long as the VDMA writes to the addresses I want I get a clear frame after removing the padding.

 

Screenshot_7.pngScreenshot_8.png

 

0 Kudos
Moderator
Moderator
1,461 Views
Registered: ‎10-04-2017

Re: Video Test Pattern Generator issue

Jump to solution

Hi @miguelcosta94,

 

I apologize for the delay, are you still running into the issue or have you moved forward?

 

Regards,

Sam

Don't forget to reply, kudo, and accept as solution.

Xilinx Video Design Hub
0 Kudos
Participant miguelcosta94
Participant
1,414 Views
Registered: ‎11-14-2018

Re: Video Test Pattern Generator issue

Jump to solution

Hi @samk,

I already solved the problem. The VDMA was always writing to the expected memory addresses. However, as I haven't configured the SCU to maintain the coherency between data cache and RAM, I always get unexpected data when performing a read from those memory addresses. In this context, there are two ways to solve the problem:

  1. Configure the SCU;
  2. Invalidate the data cache lines associated with the memory addresses used by the VDMA.

I must also mention again that YUV422 (8 bits) frames generated by the VTPG can only be reproduced by the FFMPEG if the -pix_fmt option is configured to yuyv422, as @hokim suggested. This comes as a consequence of the pixel arrangement performed by the VTPG, which follows an interleaved approach.