[spook-l] Progressive JPEG.

[Jeff Bowden]

The term you are looking for is multi-part jpeg.   There is actually a 
webcam server that supports it called camserv 
<http://cserv.sourceforge.net/>.  Alas, it does not work correctly with 
Internet Explorer because MS decided not to implement that particular RFC.

I've used camserv before. It does offer some neat features although it's 
got an unecessarily long latency and the code is not so pretty.

Nathan Lutchansky wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Sun, 14 Nov 2004, Ulrik Mikaelsson wrote:
>
>  
>
>>Allright. I'm not 100% certain that this is actually what I've seen, but I 
>>know I've seen some linux webcam server (can't recall on top of my head 
>>exactly which one) that manages to stream live "video" (as in non-stopping 
>>JPEG-frames) directly to just about ANY web-browser without any plugin 
>>(except for I.E.) utilizing some little special feature in the JPEG-encoding 
>>process, allowing for amongst other things a low-resolution version of the 
>>image to be loaded at first. But as far as I understand, it also allows 
>>full-resolution versions of the same JPEG to be overlayed on top of each 
>>other over regular HTTP, directly to just about any browser, forming a video.
>>    
>>
>
>OK, like I said, find an app that claims to do this, and I'll see if I can 
>figure out how to implement it.
>
>  
>
>>Is separate HTTP Path:s solved in CVS? i.e. could /webcam.jpg and
>>/webcam.html lead to different pages on the web?
>>    
>>
>
>Yes, the HTTP server is much easier to work with now.  You can probably 
>indirect the request-handling code through the http_location struct and 
>allow different paths to be handled by different functions.
>
>  
>
>>Will a user-contributed template for HTML-templates have a chance to be 
>>included into mainline spook?
>>    
>>
>
>Sure, with some caveats.  Any new code needs to be appropriate for running 
>on embedded systems, which means memory usage has to be carefully 
>considered.  In particular, MMU-less systems can't handle repetitive 
>allocation of large blocks, so try to keep your buffers on the stack as 
>much as possible.
>
>It now looks like I'll be rewriting the HTTP code again shortly for other
>reasons, so if you want to just put together some prototype-quality code
>to show how you'd like it work, I'll hack it in when I do my rewrite.  
>- -Nathan
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (GNU/Linux)
>
>iD8DBQFBmNVpTviDkW8mhycRAl4eAJ0Rx7tttn29gi/49NFccLIgLA262ACgjtoQ
>tSiNamOlVZIBGDT20jwn9XU=
>=GisH
>-----END PGP SIGNATURE-----
>
>  
>