cam_1.mjpg bug? cam1.jpg ok but not stream cam_1.mjpg (in ff prompts for save-as). Using WXP_COMPAT=true

[dukechem]

The /cam_1.mjpg does not live stream in browsers if build with WXP_COMPAT (but same live stream plays fine in ff/chrome using old mjpg-streamer). This bug is in the original mjpg-streamer-experimental at codewithpassion and remains in this fork. However, the codewithpassion non-experimental mjpg-streamer works fine, and is what I mean by "old mjpg-streamer".

In a nutshell: localhost:8080/cam_1.jpg displays ok in ff/chrome but neither ff nor chrome can stream localhost:8080/cam_1.mjpg in the browser window. FF prompts for save-as, chrome hangs. The live cam1.mjpg stream works fine with the old mjpg-streamer (non-experimental) build.

Steps to reproduce:

Use the WXP_COMPAT argument to cmake per Note at output_http/README.md: " If you compile with this argument the mjpg stream will be available as cam_1.mjpg and the still jpg snapshot as cam_1.jpg." Got it to build without errors.

(P.S. BTW the README.md for output_http says /cam_1.jpg which does work, but so does cam1.jpg (without underscore). Which is nice if you dislike underscores ;-) So cam1.jpg = cam_1.jpg, and cam1.mjpg = cam_1.mjpg it seems.)

Good result: the cam_1jpg works fine (which proves was WXP_COMPAT is in the build.) That is, in firefox or chrome, an updated static snapshot is seen every time you refresh browser page at /cam1.jpg or cam_1.jpg

Bad result: the cam_1.mjpg does not play in browser. Firefox offers to save a static cam_1.mjpg file, which is about 10-20 secs long and viewable with vlc. Chrome just hangs, never offering to save a file. (Actually, being able to save N-secs of mjpg to a file would be a nice option to have! But, for now, I want to be able to see the live stream!)

Expected result: the /cam1.mjpg live stream is viewable in firefox or chrome browser window, in same ways as this example http://195.67.26.73/mjpg/video.mjpg. Note the old mjpg-streamer can do exactly this. That is, cam1.mjpg streams ok in ff/chrome, just like above 195.67.26.73 site, if I run the old mjpg-streamer instead of the experimental branch (on same boxes with same cameras).

I think I applied the 2nd patch to old mjpg-streamer as mentioned by koos » Fri Feb 06, 2015 4:57 pm at [https://www.raspberrypi.org/forums/viewtopic.php?t=97983]

If I get time, I'll try to fork https://github.com/jacksonliam/mjpg-streamer and hack a bit to see if I can get cam1.mjpg to stream correctly.

[dukechem]

I think I have a fix... hacked the code a bit to provide correct boundary sequence, using this as guide: https://nakkaya.com/2011/03/23/streaming-opencv-video-over-the-network-using-mjpeg/ Also looked at working code in old mjpeg, and headers in developers toolbar.

Anyways, with my hacked httpd.c code, now http://localhost:8080/cam1.mjpg streams ok in firefox and chromium. I'll clean it up and submit a patch in next few days.

[jacksonliam]

Thanks, patch would be good.

For my curiosity, why are you using WXP mode?

[dukechem]

Because, our 3d-printer web-interface requires URL for snapshots to end in .jpg as explained below. We have several reprap 3d printers operating through a web-interface. A job can take hours/days. Recently (Jan 2016) the reprap firmware running the printer added ability to embed webcam snapshots updated every few seconds, as shown at http://reprap.org/wiki/Duet_Web_Control. At present, we can see a regularly updated static snapshot embedded in the 3d-printer web-interface, but only when we provide it a URL ending in .jpg And only WXP mode can make static snapshot abailable with URL of form: http://camera.ip:8080/cam1.jpg So WXP mode seems to be needed for us because the reprap firmware at this point cannot process a camera URL that does not end in .jpg ... that is /static_simple.html won't embed.

For those that arrive here by a web-search, there is a Jan 2017 thread on webcams for duet at https://www.duet3d.com/forum/thread.php?pid=6542#p6542

[jonlareau]

Has there been a bugfix for this yet? I also would like to be able to use the "/cam_X.mjpg" format for compatibility reasons.

[jacksonliam]

Not sure anyone has worked on patching this yet, no