Thanks for sending the project and the comparison video.
When playing an animation in the editor with physics Deterministic unchecked, the physics is updated all the time, as allowed by the rendering rate of the editor. When checked, physics is calculated more precisely and you will always get the same pose on a given frame. That uses a lot more CPU, especially for a project as complex as yours. When you export MOV (or any other image/video) the physics is calculated like when Deterministic is checked. This means you may see some slight difference in the editor when Deterministic is unchecked compared to MOV.
That said, that is not the reason for the bigger differences you see in your project between 4.3.14-beta (which has physics identical to 4.2) and 4.3.18-beta. We changed physics slightly to fix it being choppy when the render rate is low.
To see the problem we fixed, in 4.3.14-beta try playing your animation using 10% speed in the Playback view. Especially for larger movements, like the tip of the hat, the movement is very choppy. It's most noticeable when something is moving in a straight line. If you try the same in 4.3.18-beta you'll see it is extremely smooth, which is great!
Unfortunately to make it so smooth, physics behavior is slightly different. In our testing most skeletons using physics don't need any changes. In projects like yours that have a long nested chain of bones that all have physics, a very small difference in movement for each parent bone can add up to a larger difference for child bones deep in the hierarchy.
Physics forces are applied at a fixed rate. That's the FPS setting for the physics constraint. We used to just apply the whole force. This looks OK when the rendering rate is near the physics rate, but when the rendering rate is lower, the multiple frames are drawn without new physics forces being applied. Then, when the forces are applied, the bone jumps to the new position. What our change does is that forces are not applied right away. Instead they are applied over the next physics step.
For example, at 60 FPS the physics step is 1 second / 60 frames = 16ms. A force is calculated during a physics step, but not applied yet. If the rendering rate draws 4 frames for every 16ms, the rendered frames will see 25%, 50%, 75%, and 100% of the force. That makes the rendering very smooth, but it means that forces are delayed. Worst case they are delayed one physics step (16ms) and on average they are delayed half that (8ms).
This is normally such a small difference that it doesn't matter, except in long bone chains as mentioned. For projects where this causes undesirable behavior, unfortunately you will have to manually adjust the physics constraints to get the behavior you want.
The easiest way to fix your project is to increase the physics FPS. At 120 FPS the physics step is 1 second / 120 frames = 8ms, so the delay is 4ms on average and the difference with the old physics is half as much.
Another way to fix it is to increase the strength of your physics constraints to compensate for the slightly delayed forces.
We deeply apologize that this physics change requires manual fix up! We try to avoid that at all costs, but the improvements in smoothness for physics are very important.
