2017-04-28 14:58 GMT+02:00 Luke Kenneth Casson Leighton <l...@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?
_______________________________________________ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
