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?