Thanks for the guidance from both iPi and Snapz.

I was able to figure it out -- a few things I ran across:

1. Ordering rotations X/Y/Z in my matrix to match the guidance from iPi was very important.

2. Some of the Euler angles in the camera rotations had to be inverted. Either X axis, or Z axis (never Y) -- sometimes it was X, sometimes it was Z -- I don't really understand why (I had 9 cameras, depending on each camera's orientation, I'd have to invert either X or Z -- but I don't see the pattern as to "why" -- iPi if you have any advice here, that would be great. I'm just using trial an error until they match for now)

3. I had to invert X,Y,Z coords of the camera location as well. This was true for every single camera.

4. Getting my perspective plane distance correct and aspect ratio to match the original video is also necessary. This is somewhat annoying to do as iPi video export seems to be a framebuffer capture (vs original video capture size). If I reduce the iPi window size it seems to output original video, but slightly resized and clipped. I get 528x400 video (not the 640x480 that I'd expect from the Playstation Eye). iPi: Is this normal? Are you clipping and resizing the video from the cameras, maybe as part of a rectification process? Just trying to ensure I'm not doing something wrong here..

If I do all of the above, I can re-align the BVH skeleton and a virtual camera to match the camera view from my original Playstation Eye cameras. It's rather tedious (cannot be fully automated due to the rotation flip on X or Z issue) and a few items still confuse me (eg why is video exported from MoCap Studio 528x400? Is this due to rectification?)

...

If using the iPi Studio video export it captures the whole viewport, not just the video plane, so yes it is different in target scale when transferred.

Using the trial version, you don't have export ability from the recorder video, I am not sure, but if you do, that is just the video in 640 x 480 res., but only the actual performance video. Using a screen recorder to clip the view port to the video plane may work, but it will change the actual resolution a little, yes.

You can just slide the video plane in or out, or scale it a bit in Blender a little to make up for that though.

Yes, I thought some values needed to be inverted, but wasn't sure with Blender.

It's a bit off from PS Eye cam view of each video, unless your camera placement is exactly level, which I doubt, or you will get the skew in the view of each cam on the video from iPi and going to a square scene externally it throws plane orientations off a little, but I guess you figured it out.

Glad to hear you are figuring it out and good luck with the project.

...

I guess the need to invert coordinates comes from difference in handedness of coordinate systems used in iPi Mocap Studio and Blender. Although it's sufficient to invert only one of the components to make an appropriate conversion - say X or Z (you don't want negative heights for cameras, do you?).
As for angles inversion, it's strange that there is no single formula suitable for all cameras.
Video export feature in Mocap Studio is intended for preview/demo purposes. It simply captures the contents of viewport for all frames in ROI. If you need actual video footage, then you need to export from iPi Recorder, and this requires an active license for Mocap Studio on the same PC.

Quick update: I had some bugs in my code (my rotation matrix row/columns were transposed, lol) -- fixing this resolved the bizarre issue with different axis rotations for different cameras.

Now 8 of my 9 cameras align perfectly -- the 9th does not. I haven't determined if this is a issue with calibration of this camera, or a gimbal lock issue resulting from the fact that iPi Mocap Software exports only Euler angles instead of a full rotation matrix or quaternions. (iPi: Why do you export camera rotations in this way?)

iPi: Thanks for the recommendation of using video export from the Recorder. I have a Pro license so this isn't a problem for me. I wasn't aware that feature existed (I thought only the Mocap Studio offered export)

The gimbal lock relates to continuity of rotation expressed in Euler angles. However, it does not prevent any single orientation to be presented in Euler angles precisely. Therefore I believe your issue is connected to problems with calibration resulting in incorrectly detected position/rotation of a camera.