<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial,helvetica,sans-serif;font-size:10pt">Hi Ross,<br><br><br>From your previous post,<br><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt;"><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><br>> 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.)<br><br>>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.<br><br>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.<br><br>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. <br><br>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. For this issue, I believe sending SPS and PPS periodically in the stream would solve the issue.<br><br>Is my understanding incorrect? <br><br>Thanks,<br>Ganesh<br></div></div></div><br>
</body></html>