Could you guess the frame rate? The GUI was limited to 30 and it didn't show any dropped frames.
The way chdkptp live view works by polling, it doesn't know anything about the cameras actual frame rate. It just requests frames repeatedly, and gets whatever is currently in the camera framebuffer. If you request faster than the cameras actual frame rate, you get duplicated frames, and if you request slower, you miss some frames.
The frame rate you can produce is limited by USB transfer and processing overhead. The GUI should show "dropped" frames if the requested rate is faster than the combined transfer and rendering allow and gui_live_dropframes is set. By default, this is only set on Linux because the UI becomes unresponsive when an IUP timer repeatedly takes longer than the timer interval.
If you use -fps=N with lvdumpimg, it should request frames at the rate you specify, or less if it it isn't able to keep up.
How hard would it be to provide mjpeg directly?
I don't really know anything about mjpeg, so I don't know. At a minimum, it would require linking to a library with jpeg support, and converting the live view data into something the library accepts as input. I may do this eventually, but I'm not in a hurry to add extra dependencies and compile time optional features.
An alternative would be to write a shim program that reads netbpm (or raw live view protocol) on stdin and writes out mjpeg. The second option would have the advantage of allowing the conversion to happen in parallel with transfer.
FWIW, I believe the native Canon live view (as exposed by gphoto etc) the actual USB stream is mjpeg. However, we don't know how to set this up in the Canon firmware, and it's not clear if it would even be possible on cameras without Canon live view.
