(Sorry for the delay in responding to this.)
When JPEG images are transmitted via RTP, the JPEG picture header is not copied
‘as is’. Instead, to save some space, a simplified (shorter) form of the JPEG
header is packed into the RTP packet (as described in RFC 2435) before it is
transmitted. In our code, this is done automatically by the “JPEGVideoRTPSInk”
Then, when the RTP packets for the image are received at the far end (assuming
that *all* of them are received; note
<http://live555.com/liveMedia/faq.html#jpeg-streaming>!), then our code (the
“JPEGVideoRTPSource” class) automatically translates from the simplified
(shorter) version of the JPEG header back into a full JPEG picture header.
So, apparently in your case, you are (for some reason) ending up with a JPEG
picture header that’s functionally different from the one that was in the
original image. I’ll let you figure out why this is happening in your case -
but Remember, You Have Complete Source Code.
Also, I suggest that rather than use VLC as a client to test this, you use
“openRTSP” - see <http://www.live555.com/openRTSP/> - especially with the “-m”
command-line option, which tells “openRTSP” to write each incoming frame (in
your case, a JPEG image) into a separate file. You should then be able to look
at these files (and the source code) to figure out what’s going on.
Live Networks, Inc.
live-devel mailing list