HDMI in/out with video frame processing

[whai]

We need your help to recommend a stand-alone solution with its own power supply.

We want to have HDMI in and HDMI out, and to resize (shrink/zoom-in/zoom-out) and apply horizontal and vertical keystone correction to the input HDMI video before outputting to the HDMI port.

Any suggestion please?

Best regards,
Wei

[D@n]

Have you considered the Nexys Video board?

Dan

P.S.  I am not a Digilent employee.  I cannot, therefore, offer any warranties of MERCHANTABILITY, or even SUITABILITY for a PARTICULAR PURPOSE ... or any of that other legalese.  I am just offering a suggestion based upon your request.

[whai]

Thanks, Dan.

From the spec, Nexys video board could work.

But we are hoping something that doesn't require programming FPGA, but a traditional chipset with C++ solution.

--- Wei

[jpeyron]

Hi whai,

Unfortunately, we do not have a microcontroller that has hdmi. We have two board that would fit your needs the Genesys 2 and the Nexys Video. I would suggest the Nexys Video unless you would need the FMC connection. Here is a link to the Nexys video hdmi demo which uses microblaze in Vivado and C++ in SDK.

cheers,

Jon

[D@n]

@whai,

You want to do all this in C/C++?  Have you asked yourself what the speed of the microprocessor/microcontroller would need to be in order to do live screen adjustments?

On the Basys-3 board that I have, I can output a 640x480 screen at 60Hz.  Doing this means that the Basys-3 board must transmit pixels out the video port at 25Mpixels/second.  This is a VGA connection, so expect any HDMI pixel clock to be much faster.

Still, you wish to do size and keystone correction.  Let's assume you wish to do this correction using a bilinear interpolator.  I'd prefer a biquadratic, it would do a better job, but let's assume a bilinear interpolator for discussion.  That means that for every pixel, you will need to calculate left_pixel+(right_pixel-left_pixel)*fractional_position three times (one for red, one for green, once for blue). That's one add, one subtract, and one multiply per color, or 9 operations every 40ns, and that's just one direction.  You'll need to do another 9 operations in the other direction (one for X, one for Y).  It's actually worse, 'cause you'll need to be loading the pixels from some kind of memory, calculating the pixel to load from and calculating that fractional value too.  But let's just say 18 operations per 40ns, or about 2.2ns per operation, leading to a CPU clock that will need to be faster than 450MHz.

You're not going to find capability in an FPGA microcontroller.  Sorry, it's just not there.  While I'm not going to say that doing this in microblaze would be impossible (you just might prove me wrong), I kind of doubt how successful you'd be.  You might manage to do this in a 1GHz ARM, but only if you stripped any and all other software off of it and ran it bare metal.  Of course, the other problem is that CPU's just aren't designed to handle real-time data coming in and going out very well, and just because the clock runs at 1GHz doesn't really mean that it can truly do 1k MIPS, so ... you'd have that problem to deal with.

No, I think what you want is a microcontroller that controls the scaling and panning coefficients that are then used by an FPGA program.  Oh, and if you use the FPGA program, you might just manage to get that biquadratic interpolation done--it'd enhance your picture quality very nicely.  You might also manage to handle the higher video data rates, such as 1920x1280x60 frames/sec (minimum pixel clock of 154MHz or so).

I'm going to wager that the Nexys Video could handle this task quite nicely.  Microblaze is certainly available as a proprietary microcontroller.  Other, non-proprietary microcontrollers exist as well, such as OpenRISC, RISC-V, or even the ZipCPU.  Take your pick.

Also, this does sound like a fun project.  Is there any likelihood you'd be able to share your work when you finish it?

Yours,

Dan

[whai]

Agreed with your analysis, Dan.

FPGA is not the platform to do the job.

I'll search for other approaches.

Thanks.

--- Wei

[D@n]

If you agreed with my analysis, then you would come to a different conclusion: an FPGA is the perfect platform to do the job.

It's just that ... you are going to struggle to do the job in C/C++ within a microcontroller of any type.

Go ahead and search for other approaches, but my two cents says you'll come back to the FPGA approach after you do your research: An FPGA offers the fastest approach, and the only one that can handle the timing well.  Further, the FPGA offers you the opportunity to tightly integrate your user interface controls with the processing algorithm.  Unless you can find a piece of hardware that does what you want already, you're going to have to FPGAs.

Dan