[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