First, you should note that JPEG video streaming is strongly discouraged; see 
http://www.live555.com/liveMedia/faq.html#jpeg-streaming 
<http://www.live555.com/liveMedia/faq.html#jpeg-streaming>

However, our code is streaming JPEG-over-RTP correctly, according to the 
standard RTP payload format for JPEG video streaming, specified in RFC2435.  
Note that this payload format works by including - in RTP packets - only the 
essential parts of a JPEG image.  The receiving code (in our case 
“JPEGVideoRTPSource”) reconstructs a JPEG image by prepending a JPEG (JFIF) 
header.

If no quantizations tables are included in the RTP packet, then a default set 
of quantization tables are used, scaled by the ‘q factor’.  If, however, these 
default tables are not appropriate for you, then you will need to include your 
own quantization tables.  To do this, have your “JPEGVideoSource” subclass 
implement the “quantizationTables()” virtual function, and have your 
implementation of the “qFactor()” virtual function return a value >= 128.

Or you could not bother streaming JPEG via datagrams at all, because (as I 
noted earlier) it’s usually a bad idea.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/ <http://www.live555.com/>
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel

Reply via email to