Hi Ross,
>From your previous post,
> 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. For this issue, I believe sending SPS and PPS
periodically in the stream would solve the issue.
Is my understanding incorrect?
Thanks,
Ganesh
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
