I two possible solutions that use the built in wpf video technology.
The reason that I think it would be best to try to make that work is that I couldn't replicate your cpu problem, but I recognize it. That happens when the video player gets an error from the GPU and decides to go back to software rendering. Because CPU performance is a concern, you have not just the difficulty of overlaying anything a wpf control on anything but a wpf control but also the requirement that the solution use GPU acceleration.
Also, there's a slight chance that upgrading your GPU drivers will fix the second screen thing.
When I was experimenting, I found I could get a 100x100 pixel video file to loop without occasional pauses in the standard MediaElement, and I was able to get up to 800x800 pixels without pauses by using MediaPlayer and VideoDrawing, so the solution that YouTube would use is to have lower resolution versions that it can fall back to if it detects that the computer isn't keeping up.
Another solution would be to extend MediaPlayer with a buffer. The video would be playing behind the scenes ahead of the actual display, so any delays could be smoothed out. Of course, this would increase memory usage. This would also make it possible for the code to reset the player in case of a problem, like it stopping. It just occurred to me that, if you freeze a VideoBrush, it can be passed between threads, but I haven't measured the performance of this. If you are interested I'll try it.