Depending on how well you fit the skeleton inside the model you might want to instruct MeshSkinner to not "ignoreJointsUntilInsideMesh". Below is a version of my example code with makeSkeleton() instead of makeDebugSkeleton(). I had to set ignoreJointsUntilInsideMesh=false because when makeDebugSkeleton() is called with a jointSize!=0 meshes are created to visualize the joints, causing makeSkeleton() to look different. I've made a note to try to fix this if I update MeshSkinner (will make the work routine not take meshes on the skeleton GameObjects into account).
BVH bvh = new BVH("C:/temp/notch-format.bvh", -10);
bvh.scale(100);
GameObject skeleton = bvh.makeSkeleton(); //changed line
MeshSkinner.DESTROY_ORIGINAL_MESH_RENDERER = 1; //new line
MeshSkinner ms = new MeshSkinner(GameObject.Find("dummy_obj"), skeleton);
ms.workAndFinish(ignoreJointsUntilInsideMesh:false); //changed line
Animation a = BVH.animateSkeleton(skeleton, bvh.makeAnimationClip(-36, -10, true));
While testing with Unity 2019.1 it seems like an old quirk have been fixed in Unity now, creating "SkinnedVersion" GameObjects is no longer needed. That's why I'm setting DESTROY_ORIGINAL_MESH_RENDERER to 1 above, it's not needed but should free up some resources while the game's running.
Another issue I noticed with Unity 2019.1 is that system locale matters now (coutry number formats, "comma instead of period"). Thanks to this BVH could throw FormatException when parsing numbers. Hopefully this is just something Unity has overlooked and will revert, I don't see it as a good thing when code don't run the same on different computers simply because comma is expected instead of a period. I'll take the possibility into account if I update BVH but in the meantime this can be fixed by defining the desired culture in your code (only needs to be done once, before the BVH class is used):
System.Threading.Thread.CurrentThread.CurrentCulture = System.Globalization.CultureInfo.GetCultureInfo("en-US");