Selecting a Digital Signal Processor for a Specific Image Sensor
Good approach to first do a rough calculation of the bandwidths you need.
Couple of remarks on that:

You forgot a factor of 3, that camera has three &quot;color pixels&quot; per image pixel
Your use case screams &quot;I should be using a commercial off-the-shelf USB camera&quot;; don't engineer something very complex if it doesn't have a value proposition over what you can buy. If the value proposition is &quot;I can learn how to work with cameras, and DSP&quot;, I'd frankly start smaller, and learn how to work with camera images on a PC in software before moving out part after part to an embedded processing platform.
You try to downplay the camera interfacing, but it's really a critical part here: in need to interface digital buses for which their processors have no dedicated interface, engineers turn to FPGAs. You'll need one, just as the &quot;glue&quot; between your camera
Your approach of using an MCU betrays that you're not overly familiar with what these can and can't do. Wrong order of magnitude: for this kind of problem you need what is usually sold as &quot;application processor&quot;, with plenty RAM, and things like interfaces for network hardware and the opportunity to run an OS reasonably fast.
You picked an oldish low-power DSP core. That 400 MHz thing can do way less than modern application processor CPUs can do. For example, every SSE-enabled x86 CPU can do two multiplications at once, just like that DSP core, but they tend to run much faster.
You're planning to stream something between 1080p and 4k video .. to the internet. You really need a fast internet uplink to do that. You might want to download a 4k video snippet and look at the amounts of bits per second that needs.

So, all in all:

You need an application processor, which take your MCU completely out of business (you will probably still need an MCU, to do things like turning on power to the different power rails of your other components in the right order, but not at all involved in handling the camera data)
You need a device with a MIPI interface. If you're able to buy in big numbers, you'd typically get a camera or smart phone System-on-Chip that has a CPU (see above) which has such an interface. In your case, it's going to be an FPGA, or a MIPI-to-USB3 bridge (cypress sells these). In any way you do it, getting the interface right isn't trivial.
I don't really see how a DSP core fits in here in practice: for the data / camera handling, your application CPU does the most. For the video encoding, you'd typically use a dedicated encoding accelerator that does the computationally hardest part of it.

All in all, this sounds like you'd start with a small x86 mainboard (there's way smaller form factors than µATX, but honestly, µATX isn't so large for prototyping), and get a camera that you can attach to that - and that would usually simply be a high-quality webcam or DSLR.
For highly integrated systems, going the FPGA route is very attractive, and you can do a lot of computation by writing the right hardware description - problem is, that takes a lot of experience. For even higher integration, you'll find ASICs that are both pretty camera-specific and use-case-specific that take on the task of handling everything from camera to radio interface. In fact, DJI has bought a semiconductor manufacturer just so that they have that kind knowledge in-house, although they are by no means a semiconductor company – they sell video drones.
Honestly, I'd call the FPGA approach &quot;unrealistic within the next year&quot;, given your current understanding of the matter, sorry. The ASIC route is impossible, since production of a single high-speed wafer costs millions, and you don't have a silicon design team.