50% efficiency - so ~4200 MBytes/sec to work with.
So just for fun, the calculations with 1080p60 and three cameras connected, two displays: (I know this sounds impossible, and I think it is, I just can't prove it)
Video Source #1 -> RAM -> IC - |
Video Source #2 -> RAM -> IC - Combine with #1 -> RAM -> Display Controller w/combiner
Video Source #3 -> RAM -> IC - Combine with overlay -> RAM -> Display Controller w/combiner
Overlay -> RAM -> IC - |
That's 14 memory accesses. 1080p60 is 248,8 MBytes/sec (2bytes per pixel), so that means 3483.6 MBytes/sec. Theoretically OK, right?
1. Any reason this _wont_ work? (Any other limitations that I haven't caught? What would the delay be? Any restrictions to the number of parallel video paths at once?)
2. If so, what is the most the i.MX6 could handle, given the optimal conditions?
3. How much bus load and memory accesses would H.264 encoding with 1080p30/720p30/720p60 need?
4. How much cpu load is needed to set up and "control" all these processes.
I would really like an application note on this kind of calculations (I might have missed it, don't shoot me - I did look for it). I've found some information here and there, a few slides from some presentations, but gathering all of this informations _and_ seeing the bigger picture is difficult.