<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-04-28 14:58 GMT+02:00 Luke Kenneth Casson Leighton <span dir="ltr"><<a href="mailto:lkcl@lkcl.net" target="_blank">lkcl@lkcl.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
 in the case where you have something that falls outside of the custom<br>
silicon (a newer CODEC for example) then yes, an FPGA would *possibly*<br>
help... if and only if you have enough bandwidth.<br></blockquote><div><br></div><div>That is what I was talking about.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
 video is RIDICULOUSLY bandwidth-hungry.  1920x1080 @ 60fps 32bpp<br>
is... an insane data-rate.  it's 470 MEGABYTES per second.  that's<br>
what the framebuffer has to handle, so you not only have to have the<br>
HDMI (or other video) PHY capable of handling that but the CODEC<br>
hardware has to be able to *write* - simultaneously - on the exact<br>
same memory bus.<br></blockquote><div><br></div><div>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. </div><div><br></div><div>I found a nice presentation on using FPGA's for video codecs.</div><div><a href="https://www.ece.cmu.edu/~ece796/seminar/10/seminar/FPGA.ppt">https://www.ece.cmu.edu/~ece796/seminar/10/seminar/FPGA.ppt</a><br></div><div><br></div><div>The most facinating option I found is to reconfigure the FPGA for each processing step. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
 the point is: if you're considering using an FPGA to accelerate video<br>
it's gonna be a *really* big and expensive FPGA, and you would need to<br>
implement something like PCIe just to cope with the communications<br>
between the two.<br>
<br>
 costs just escalated way beyond market value.<br>
<br>
 this is why companies just simply... abandon one SoC and do another<br>
one which has an improved custom CODEC silicon which *does* handle the<br>
newer CODEC(s).<br></blockquote><div><br></div><div>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. ;-)</div><div><br></div><div>Speaking of which any plans for a en/decoder module(IP Block is therm right?) in the new SoC? Or leaving that out? </div></div><br></div></div>