That's easy, a packet goes into the bridge it the bridge's output is not blocked, and does not go if the output is blocked (and in this case if there is another pipe leading away from the input, the packet continues there).
What's also important to understand is that packets do not travel continuously like the animation shows, but they jump to the next pipe segment instantly (once in each second). It's easy to observe this if you fill a pipe with heterogeneous content (like different materials, they are the easiest to see) and hold your mouse over a pipe segment and watch the content of the pipe. So "being blocked" means that at the moment this jump occurs, the packet in the pipe segment under the output port has nowhere to go, and not blocked means this packet can jump to somewhere else, making free space for the packet coming through the bridge.
There is one more important behavior: if you have a pipe that has a continuous packet flow, and you put the bridge output on the middle of this pipe, the game will prioritize the flow in the pipe. To put it another way, if the pipe segment under the bridge output has an incoming pipe, a packet will be drawn from the incoming pipe and not through the bridge. It fits with the general mechanism: packets already in the pipe make the pipe blocked, blocking the bridge.
Maybe one more thing that might be confusing based on the animation: when a packet enters the bridge, it means it appears instantly on the output. The animation looks like it is entering the input pipe segment, but the input pipe in this case actually remains empty. If the packet cannot enter the bridge, it remains in the input pipe segment, and the animation looks exactly the same.
(NB. this explanation assumes full packets, bridges also handle partial flow, but I guess you already noticed that.)