Maximum pixel clock for gaming overlay(refresh rate and resolution)

[omerk...@gmail.com]

Most gamers prefer 1920x1080 144hz over hdmi or display port these days. Can snicker doodle black handle such resolution while inserting an overlay?

[weath...@krtkl.com]

No but maybe Yes.

No, as 1920x1080 144Hz is a 357MHz pixel clock rate which is above the TDA19988 HDMI transceiver capability on the piSmasher HDMI in/out baseboard.

Yes, as with a different (read: more expensive) transceiver would be able to do that.  You'd likely need an HDMI transceiver with LVDS I/O designed for 4K video.

Generally available HDMI framers/transceivers with pixel clock rates above 297MHz are a bit more rare at the moment but some are starting to come to market.

Most often, at those levels due to signal integrity challenges multi-gigabit transceivers directly built into the FPGA/GPU/CPU are being used to produce the signalling for HDMI and DisplayPort (along with expensive IP in the case of HDMI).

-Jamil

[Jamil Weatherbee]

The 144Hz we are not sure about / have not tested because that is not a standard HDMI mode.  There is no reason it should not work provided the pixel clock is <= 165MHz but again it has not been tested and these special modes require correctly configuring special registers in the HDMI transceivers to achieve the right timing.

On Jul 22, 2018, at 1:03 PM, Lambaya Püf De! <omerk...@gmail.com> wrote:

Hi again. Your forum seems somewhat broken and i didn't recieve any information for 2 weeks. As i said before i am inerested in inserting a overlay(must be not noticable very low latency for gaming purpose) into hdmi/dvi stream. Video resolution could be up to 1024x768 144hz. Can you implement such thing or maybe for a lower resolution? A board called netv2 has the exact thing i wanted but it wont be available for next 10 more months. It simply lets you use hdmi output of a RPi for overlay data and supports 1080p60fps already.

On Tue, Jul 10, 2018 at 3:46 AM, Jamil Weatherbee <weath...@krtkl.com> wrote:

Bush, any thoughts on this?

On Jul 9, 2018, at 2:59 PM, Lambaya Püf De! <omerk...@gmail.com> wrote:

What about 1024x768 144hz?

TDA19988 can support all major PC Standards up to 165 MHz  written in technical document.

1024X768 V FREQ 75

--
You received this message because you are subscribed to a topic in the Google Groups "snickerdoodle forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/krtkl-snickerdoodle/h9imXQyYitg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to krtkl-snickerdoodle+unsubscribe...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/krtkl-snickerdoodle/3abac5b2-4474-4e9a-956d-74e16df968b9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Jamil Weatherbee]

I’m not sure what is meant realistically by “zero” latency since there will be significant latency in the frame buffers at the source and destination side of the link.

If you are sourcing from a PC/RPi it takes 16.6ms (at 60Hz) to send out each frame so it is possible if you’ve just set a pixel in the inactive frame buffer that up to 16ms will pass before it becomes the active frame and the pixel is sent out (if the active frame is just at that moment beginning to be sent out).  This avoids tearing and glitches in the graphics during redraw.

Similarly, at a sink like a monitor there will be a frame buffer due to the need to potentially scale and frame rate convert the image to the native resolution and refresh rate of the LCD/OLED panel etc. Perhaps some displays can bypass/shorten this if you are running native resolutions/rates but it is very common for video hardware scalers especially with multiple inputs like a monitor to have an integrated RAM holding an entire frame at a time so that would be a detail you’d have to have some advanced equipment to measure on a random monitor.   Here is an example of the chip you might find in a monitor: https://www.st.com/resource/en/data_brief/stdp7320.pdf

In terms of the data passing through the piSmasher + snickerdoodle the data comes in/out from the HDMI transceivers essentially as raster scanned pixels at the pixel clock rate (neither transceiver has any kind of video buffer) so depending on the IP you are using to do the overlay (row oriented would be common for efficient memory access) you might have something like 1 or 2 video row delays.  At 1080p60 this would be ~ 2 / 1080 / 60 = ~31 microseconds.

Both the NeTV2 and snickerdoodle use essentially the same generation of Xilinx silicon (snickerdoodle has Zynq-700 = Artix-7 silicon + integrated ARM Cortex;  NeTV2 uses Artix-7 silicon alone with multi-gigabit transceivers for the HDMI TMDS link).

The difference is that the HDMI TMDS decode is being done in the FPGA fabric on the NetTV whereas the piSmasher+snickerdoodle use commercially qualified NXP HDMI transceivers.   

This difference is what allows the NeTV2 to bypass HDMI DRM in theory. I won’t explore the legal implications of that here.  You can read about suing the government for fair use of HDMI content here: https://www.eff.org/cases/green-v-us-department-justice

My impression (opinion only) is that the NeTV2 is focused on addressing an array of DRM/FOSS/Libre/DMCA/fair use issues.  BTW, the guy that designed it we’ve had some good conversations with and he is a very knowledgeable engineer and businessman.  

I don’t think you are going to find much difference latency wise but clearly we are addressing a different set of potential applications so hopefully that informs your choice of platform.

-Jamil

On Jul 23, 2018, at 3:19 AM, Lambaya Püf De! <omerk...@gmail.com> wrote:

What about latency? How many miliseconds would it be? Netv2 claims it has near 0 for video and 2-4 frames for overlay.

Is such functionality(inserting an overlay) available right now? If not when you are going to implement it? Is there a roadway or should i wait little more before buying one piece from mouser? Does the version of snickerdoodle makes any difference for this purpose?