Kevin Marks busts a move:
> At 4:53 PM -0800 11/7/00, Jim Van Vorst wrote:
> >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.
I selected Photo JPEG, which produced a file with a series of stand-alone
JPEGs with restart markers. I don't use restart markers (though I probably
should). Does QT expect/require them?
I don't have OS X server running here, which is apparently required for QTSS.
Will something else do this, like the Darwin source?
> 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.
I'm skipping all my tables and markers and starting with my scan line data.
> 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.
I'm using YUV 4:2:0, so type code 1.
> 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.
All that's supposedly what I'm doing. The RTSP negotiation seems to be happy,
then I send my JPEG data (starting with the first scan line) using code
verbatim from Appendix C of rfc 2435 (but no restart header). I'll play
around with it some more and see if Darwin can play my QTPlayer-generated
hinted jpeg movie.
Thanks for all your help.
Jim Van Vorst
