[Live-devel] Re: erratic MJPEG streaming

[Ross Finlayson]

>Thus, I reach the conclusion that my code has to avoid delivering a (char 
>*) with the JPEG
>header included: only the JPEG data has to be delivered, and I have to 
>read the file
>headers to fill the JPEGVideoSource parameters. The quality factor must be 
>guessed, as it
>is not in the header, but an incorrect value wouldn't mess all the MJPEG 
>payload decoding.
>
>Questions:
>         -is this correct?

Xavier,

That's correct.  The original JPEG header from your images should *not* be 
included with the RTP payload - because the information necessary to 
reconstruct the header (type, width, height, Q factor) is already carried 
in the much shorter, RTP-specific header that's in each packet.  One of the 
goals of the RTP payload format for motion JPEG was to save space in 
network packets - by not including the full JPEG header.  The JPEG/RTP 
receiver code (for MPlayer and VLC, this is the LIVE.COM 
"JPEGVideoRTPSource" class) will reconstruct the original JPEG header 
before passing each frame to the renderer.

FYI, an example of a working JPEG/RTP stream is
         rtsp://ip6streamer.ctie.monash.edu.au/darkjnoaudio.mov


	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>