At first blush it seems embarrassingly parallel - with each matching frame (or block of several frames) from each camera being chunked off in parallel. But it can't be that straightforward, can it?

You would probably want to make sure that the tone mapping used from one frame to the next is relatively consistent.

What this means is that if you have a scene that is tone-mapped to just fit within the dynamic range of the monitor, and then the brightest lights in the scene are cut, you have a choice: either use a tone mapping that is similar to the previous frame, resulting in an apparently under-exposed frame that uses only a fraction of the dynamic range of the monitor, or use a radically different tone map, which would replace the sudden darkening effect with colors shifting all over the place.

A naive automated tone-mapper might take the latter approach in order to be embarrassingly parallel, but in order to look natural, the tone-map would have to shift gradually, just like pupils dilate gradually. These inter-frame data dependencies will make tone-mapping video comparable in complexity to video encoding. It also means that it is unlikely to be a task that can be fully automated, because there is a tradeoff between inter-frame contrast and intra-frame contrast that can only be resolved with knowledge of the artistic intent of the sequence.