Sanket, you've shared your servicer, but you haven't shared the code that's enqueueing data into your camera_buffer. If you have a single writer enqueueing objects into a global buffer at a constant rate, then when you have one active RPC, you'll be getting the expected result -- each frame is delivered to the client. But if you have two connected clients you'll have two readers on your queue and each frame will be received by only one of them. So you'll basically be sending even frames to one client and odd frames to another.
What you do instead will depend on the sort of behavior you want. If you are okay with potential loss of frames on a stream, then you can do something very simple. Keep a global variable with a single frame, along with a threading.Lock and a threading.Condition. The writer will signal all awaiting threads each time it changes the frame. Each stream will be waiting on the condition variable, read the frame when signalled, and send it on its stream.
If you can't tolerate the potential loss of frames, then you'll need a data structure a little more complicated. Each frame needs to be kept in memory until all readers have received it. Only then can it be purged. You'd keep frames in a global buffer. Each time you pull a frame from the buffer, increase a count on the frame. Whichever reader happens to read it last will observe that the count has reached the global number of readers and can purge it from memory. Then you'll need to factor in the fact that clients can come and go, so that the total number of readers may change at any time.
Regardless, the issue isn't really with gRPC. This is more about multithreading in Python.