[Live-devel] H264 Headers in live stream

[Ross Finlayson]

>  > The standard solution to this problem is for the RTSP server to 
>include the data for these special PPS/SPS NAL units in the SDP 
>description > that gets returned in response to a RTSP "DESCRIBE" 
>command.  (This is done in a "a=fmtp:" line, using the 
>"sprop-parameter-sets" parameter.)
>
>>Fortunately, our server implementation does this automatically, 
>>*provided that* you pass an appropriate 
>>"sprop_parameter_sets_str" >parameter >to 
>>"H264VideoRTPSink::createNew()".  In particular, this 
>>"sprop_parameter_sets_str" should be the Base64-encoded strings 
>>for >the PPS and >SPS NAL units, separated by a comma (',') 
>>character.
>
>I have a small doubt. Typically, we would be invoke 
>H264VideoRTPSink::createNew for every new client session,which would 
>typically be reading from different ports. In this cse, passing the 
>sprop_parameter_sets as described by you would definitely solve the 
>problem.
>
>However, I was talking to Sunder (as he is geographically close to 
>me) yesterday. If I understood his implementation, he has a single 
>source and single H264VideoRTPSink created to stream out the data. 
>The same stream is being read by multiple clients (VLC in this case) 
>using the same URL.
>
>For this implementation, if I understand correctly, for every new 
>clinet createNew wouldn't be invoked and hence, these clients may 
>not get the sprop_parameter_sets.

Yes they will.  Even though - in this case - only one 
"H264VideoRTPSink" is created, it will retain its special data (for 
the SDP "a=fmtp:" line), and will deliver it (in the SDP description) 
to each new client.

Also including the PPS and SPS NAL units in the actual data stream 
won't hurt, but is not necessary in this case.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/