I'm writing my own little audio/video streaming server that will send out RTP
payload types 0 and 26 (ulaw audio and JPEG). I'm trying to send this to the
QuickTime player. I can get audio to work. When I try JPEG, RTSP seems to be
happy and I send the JPEG data over RTP, but it doesn't display and I get no
error messages about what failed.
I've been searching for a RTSP server which will stream JPEG so I can at least
prove out that QuickTime will accept it as per the RFC. I've looked at the
Darwin code and see no mention of JPEG; it appears to only stream QuickTime
movies.
QuickTime Movies are large; they contain multitudes.
My questions are:
o Is it true that QuickTime will accept a JPEG/RTP stream (rfc 2435)?
Yes.
o Does anyone know of a reference implementation of the server side which will
send JPEG?
o Are there any RTSP URLs that I can point my QuickTime player to which will
send me a JPEG?
If you open a movie in QTPlayer, and export it with JPEG compression,
checking the box under the Options button that says 'Optimize for
Streaming' it will create RFC 2435-compliant JPEGs. If you then hint
this movie and put it on a QTSS server, it will send an RFC-compliant
JPEG stream using payload 26.
Here is some info that may help with interoperability:
Ordinary JPEG files contain byte sequences called markers, which contain
information such as the quantization and variable-length-code tables used to
encode the image. RTP JPEG packets are not supposed to contain these
markers. The introductory passages of RFC 2435, "RTP Payload Format for
JPEG", are a fairly readable introduction to the situation.
Note in particular the following passage from RFC 2435:
In practice, most of the table-specification data rarely changes from
frame to frame within a single video stream. Therefore RTP/JPEG data
is represented in abbreviated format, with all of the tables omitted
from the bit stream where possible. Each frame begins immediately
with the (single) entropy-coded scan. The information that would
otherwise be in both the frame and scan headers is represented
entirely within the RTP/JPEG header (defined below) that lies between
the RTP header and the JPEG payload.
look in your packets in case you are leaving these in by mistake:
FF D8 is a JPEG Start Of Image marker.
FF E0 starts a JPEG APP0 marker.
FF DB starts a JPEG DQT marker; it's followed by quantization table data.
This should not appear in RTP JPEG. Quantization tables are either
specified as single-byte IJG JPEG quality values, or as specified in 3.1.8
of RFC 2435.
FF C0 starts a JPEG Start Of Frame (type 0) marker, also not meant to appear
in RTP JPEG. This marker tells us that the frame's size is 0x0140 x 0x00f0,
or 320x240, YUV 422. At least this agrees with the RTP JPEG header.
FF C4 starts a JPEG DHT marker; it's followed by huffman table data. This
should not appear in RTP JPEG. The default huffman table values must always
be used.
FF DA starts a JPEG Start Of Scan marker. The first byte of
entropy-coded data comes after the Start of scan. That byte should
be the first byte
after the RTP JPEG header.
