> 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/
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
