About display 1280x720 video on DM355

I can think of two things why this may happen

1) You are not using enough buffers.  Keep in mind that due to B-frames (which may require decode algorithm to keep two frames), you need triple buffering of video frames (up to two for decode and one for display).

2) If you have allocated enough frames via FifoUtil_put(), then there is always the possibility the frames are not being freed for re-use correctly (done via VIDIOC_DQBUF ioctl)

I am curious how you are getting such a resolution out of the DM355, I assume you have a custom board? If so, in addition to the demo code you may have to do some driver modification to allow such resolutions, as the EVM as is cannot output HD signals.

This is a very good point; I assume if you are seeing video at this resolution, you have some type of daughter card.  Did you make any changes to the Linux Kernel drivers?  You just mention the application.  If you can give us a more detailed picture of your setup, perhaps we can offer better advice.

Yes, I developped a custom display device to support HD output and I have changed the kernel driver to support 1280x720 output. Now when I only played the HD video without audio, It can work well. I can not know if the GStreamer can solve this issue on DM355? Thanks very much.

Best Regards,

Jeff

And I changed the demo source code to display HD video using ping-pong buffers(originally use dma copy in demo source code). When I used dma copy to display HD video, I found some noise. So I used ping-pong to do it. Now there were three system frame buffers on kernel.

How to use more buffers to solve this issue of pipe deadlock when played the HD video with audio? thanks.

I am not sure that GStreamer would be of much help here, as that primarily deals with handling containers and combining audio and video, so if your problem is at the application level of handling buffers than GStreamer may make a difference, though if your problem is at a lower driver level with how the driver is handling buffers than GStreamer could have the same problems.

Three buffers should be adequate, if you are still getting stuck on the fifo request error than it could mean that you are seeing Juan's second issue, if your application is not freeing the buffers at the same rate it is aquiring them. Though it seems strange to be related to audio if this is the case, as an inconsistency in freeing the buffers should show up regardless of the audio. The fact that audio is interfering with video makes me wonder if your driver modifications have hard real time deadlines that could be getting broken by the addition of the audio load on the system, or if you are running out of space to allocate buffers.

Hi, I am using DM355 EVM board, I try to display GUI on LCD with 720*480, but my LCD display some flickering horizontal line when I type some command on console.

I have run the TI patch "writeb 20000020 0 10" to increase bandwidth of DDR2, it has some effect (display some shorter lines ), but how can I do to totally fixed it?

Flickering can be caused by setting video timing registers inappropriately or by DDR2 bandwidth limitations.  Does going to 640x480 eliminate flickering?  If so, you may be indeed looking at bandwidth limitations; below are some tips that may help

-use RGB565 instead of RGB666 or RGB888

-use video0 window instead of video1 (vide1 is slower)

-try to disable the other OSD window if it is not bieng used.

Also, if you can list all the DDR2 activity that is currently taking place in your system (e.g. capture to DDR2, resize from DDR2 to DDR2, display from DDR2...), we may be able to provide additional advice.

I am using RGB565, and the capturer and resizer didn't open yet, I only try to display a GUI.

Now, I can eliminate the flickering by setting the following register:

        dispc_reg_out(VENC_OSDCLK0, 1);
        dispc_reg_out(VENC_OSDCLK1, 2);

        dispc_reg_merge(VENC_DCLKCTL,
                        1 << VENC_DCLKCTL_DCKPW_SHIFT,
                        VENC_DCLKCTL_DCKPW);
        dispc_reg_out(VENC_DCLKPTN0, 0x2);
but I can only see the left section of my GUI, and I found that VCLK  was decreased to 13.5M from 27M, but Hsync didn't change at all.

I think the Hsync must be too fast according to my 13.5M VCLK , so I want to decrease Hsync to Hsync/2, How can I do that ? I don't know which register can divide Hsync by 2. 

Interesting, if I understand correctly programming DCLK allows you to slow down VCLK used for display but pixel clock generating HSYNC and VSYNC remains same; if this is the case, you can change the values of HSTART and related registes to change the pixel clock at which HSYNC occurs at.

yes, I can slow down VCLK, and I have done as your suggestion, I can set Hsync to Hsync/2 now. This can save some bandwidth of DDR2, and kick out the flickering of LCD(720*480@30fps).

thank you very much.