Questions about adding support of crop feature to existing HDMI2USB-Litex-firmware

[Nancy Chauhan]

Hello TimVideos.us ,

I have been trying to add support of crop feature to HDMI2USB-Litex-firmware . Initially I coded for clipping off the video/image from top/bottom/left /right (40px) and then i aimed at working on Pixel duplication so that final output is zoomed in on the screen .

While testing it on board "Numato Opsis", I could observe the following output https://www.youtube.com/watch?v=p3Bl_UAnbkM, There was a problem of flickering In clipped off part . I tried to reduce the code But the result remained the same . Can someone tell me the reason why this is happening and the solution to it .

Pull Request : https://github.com/timvideos/HDMI2USB-litex-firmware/pull/444

[Rohit Kumar Singh]

HI Nancy,

Are you getting the similar behavior when the video source is set to pattern instead of HDMI input? Currently the source is set to HDMI input as I can see.

-Rohit

--
You received this message because you are subscribed to the Google Groups "hdmi2usb - A HDMI capture solution" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hdmi2usb+unsubscribe@googlegroups.com.

[Nancy Chauhan]

Hello , I am not getting the same output with pattern . It remains constant there

To unsubscribe from this group and stop receiving emails from it, send an email to hdmi2usb+u...@googlegroups.com.

[Tim 'mithro' Ansell]

Hi Nancy,

I haven't had a chance to look at your code / example -- but it sounds like you are using the CPU to manipulate pixels in the memory buffer? If so you should know that  CPU inside the HDMI SoC is not fast enough to do manipulation of the full FPGA frame (it's okay for small things). 

For cropping / scaling you will need to modify the DMA HDL code which takes the pixels from the HDMI input and writes them to memory.

Tim 'mithro' Ansell

To unsubscribe from this group and stop receiving emails from it, send an email to hdmi2usb+unsubscribe@googlegroups.com.

[Rohit Kumar Singh]

Hi Nancy,

Tim has already conveyed my apprehensions regarding using CPU for manipulating the framebuffer. It is simply not fast enough. We need to do this via HDL. For using CPU to repaint framebuffer everytime using ` crop_service `, you would also be blocking other services since that function will take a lot of time to return.

Now, as for the behaviour you are seeing, my guess is that you are only manipulating one framebuffer, whereas, the HDMI inputs have 2 (or 3? I not looked at the design in quite a while) framebuffers. So, you may be writing to only one framebuffer, whereas the other framebuffer is untouched. Now, the HDL design is such as it uses both framebuffers for displaying the output (i.e, 1st region for sometime, and then 2nd region for the sometime, and back to 1st region...this goes on.) Since you are manipulating only 1st framebuffer, you are only getting correct output when the hardware fetches the pixels from the 1st region, and when it fetches pixels from 2nd region, you get full image. The reason why you don't see this issue when using pattern as input source is because the pattern has only one framebuffer (at this stage you should know the reason why pattern has only 1 frambuffer, whereas the HDMI inputs need 2-3 or more framebuffers, if not, then please read this https://en.wikipedia.org/wiki/Multiple_buffering ). This is all an informed, best-guess hypothesis though.

Coming back to HDL vs CPU. While you might get this issue fixed, you are currently attempting in incorrect direction as Tim said in the previous mail. We need to modify the HDL (especially the DMA section to achieve this in practical way).

- Rohit