[Live-devel] Wrong reconstructed JPEG Header after RTP Streaming

Ross Finlayson finlayson at live555.com
Wed Jul 15 05:14:35 PDT 2015


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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20150715/856c4c19/attachment.html>


More information about the live-devel mailing list