With a live stream, it's generally not parallelizable at all. You won't have future frames to work with unless you add a huge delay in the stream, which generally doesn't mesh well with doing something live.
5 minute delays are common on twitch, especially to circumvent stream snipers. Totally live video is a liability actually and I would guess most live broadcasts have a delay.
In any case, I wasn't referring to inter-frame parallelizability, I was referring to intra-frame parallelizability which doesn't require a delay.
I am not going to say it never happens but purposely induced delays are very rare. You have to remember that Twitch is a community and the people watching communicate with the streamer through chat. Getting a response to something you say in chat 5 minutes later is not a workable solution.
Now, this works fine for large broadcasts where there is no two way communication between a streamer and their followers or in some type of competitive situations, but that is not the norm.
Twitch is just one example, and I'd assume most live video viewed would benefit from a lower delay. That goes for everything from security cameras to sports to video chat. I'd bet that for the vast majority of live video a lower delay would not be a "liability", but rather a plus.
Iter-frame parallelizability is made possible (at least in the context of h264) by using slices. It comes with a minor penalty in the resulting data compression ratio.
In any case, I wasn't referring to inter-frame parallelizability, I was referring to intra-frame parallelizability which doesn't require a delay.