2017-04-28 14:58 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
in the case where you have something that falls outside of the custom silicon (a newer CODEC for example) then yes, an FPGA would *possibly* help... if and only if you have enough bandwidth.
That is what I was talking about.
video is RIDICULOUSLY bandwidth-hungry. 1920x1080 @ 60fps 32bpp is... an insane data-rate. it's 470 MEGABYTES per second. that's what the framebuffer has to handle, so you not only have to have the HDMI (or other video) PHY capable of handling that but the CODEC hardware has to be able to *write* - simultaneously - on the exact same memory bus.
I Overestimated the capabilities of an FPGA. I've just read You need two/four FPGA linked to do H264 in realtime. Or a full new one. FPGA's also are usually are very slow.
I found a nice presentation on using FPGA's for video codecs. https://www.ece.cmu.edu/~ece796/seminar/10/seminar/FPGA.ppt
The most facinating option I found is to reconfigure the FPGA for each processing step.
the point is: if you're considering using an FPGA to accelerate video it's gonna be a *really* big and expensive FPGA, and you would need to implement something like PCIe just to cope with the communications between the two.
costs just escalated way beyond market value.
this is why companies just simply... abandon one SoC and do another one which has an improved custom CODEC silicon which *does* handle the newer CODEC(s).
Hmm. So for longevity the video decoder should be outside the SoC and be serviceable... Nah just buy a new EOMA card and keep the rest. ;-)
Speaking of which any plans for a en/decoder module(IP Block is therm right?) in the new SoC? Or leaving that out?