[Live-devel] sdpLines problem
Ross Finlayson
finlayson at live.com
Tue May 3 11:37:57 PDT 2005
> Maybe you need a frame to extract information?
That's correct. (See the code for
"OnDemandServerMediaSubsession::sdpLines()" and
"MPEG4VideoFileServerMediaSubsession::getAuxSDPLine()".) The issue is that
- for MPEG-4 video streams - the SDP description returned in response to a
RTSP "DESCRIBE" command must contain a "a=fmtp:" line containing a
"config=" string. This 'config' string is the ASCII hex representation of
the MPEG-4 stream's "Visual Object Sequence" header. (This header differs
for each stream; therefore, the stream needs to be read in order to get it.)
Therefore, MPEG-4 video streams get read twice: first (briefly) in order to
respond to the RTSP "DESCRIBE" command, and again later when handling the
RTSP "PLAY" command. (Note that this is true only for MPEG-4 video streams
(although it will probably also be true for H.264 video streams - for the
same reason - once streaming for those is supported).)
Note also that this means that for a MPEG-4 video stream to be streamable,
it *must* contain a "Visual Object Sequence" header at or near the
beginning of the stream. (If you're streaming from a file, it's sufficient
for the "Visual Object Sequence" header to occur just once, at the
beginning of the file. However, if you're streaming from a live source,
then it must contain "Visual Object Sequence" headers periodically.)
> Is that necessary? The problem is that my grabber is extern from
> the
> FramedSource derived class and in this way the first frame
> (usually a
> key-frame, I am streaming in m4v format) is lost.
Too bad. If this is a problem for you, then you will need to change the
implementation of your source object to deliver data beginning from an
I-frame each time one is created.
Ross Finlayson
LIVE.COM
<http://www.live.com/>
More information about the live-devel
mailing list