It could simply be the most recent I-frame from the other stream in question. That would require neither decoding nor encoding on the server's part, merely buff

It could simply be the most recent I-frame from the other stream in question. That would require neither decoding nor encoding on the server's part, merely buffering, and I suspect transport-stream libraries have very optimized functions for finding I-frames. Furthermore, once a user starts flipping channels, since most flipping is just prev/next, you could start proactively sending them the frames for the adjacent channels of where they are, and reduce the show-delay to nearly nothing at all. When they calm down and haven't flipped for a while, stop this to save bandwidth.