2009/9/10 <span dir="ltr"><<a href="mailto:spopo316@yahoo.com.tw">spopo316@yahoo.com.tw</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font-family: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; font-size: inherit; line-height: inherit; font-size-adjust: inherit; font-stretch: inherit;" valign="top">
<br><br>But when I streamed the H.264 file by unicsat method successfully , the sprop-parameter-sets has been set “h264”. Therefore i think the sprop-parameter-sets=h264 does't influence the stream when using multicast method. Is it right?<br>
<br></td></tr></tbody></table></blockquote></div><br>No, that's not right. For the decoder to understand your H.264 stream, it is crucial that the SPS/PPS info is communicated over a reliable protocol. If you are not sending in in the sprop-parameter-sets argument, how are you conveying it? Note that sending it in the actual stream is not recommended (see section 8.4 of RFC3984). Some people mistakenly think their Live555/H264 implementation "works," but really they're just conveying SPS/PPS info through the lossy RTP channel, which is strongly discouraged by the RFC:<br>
<br><pre>The picture and sequence parameter set NALUs SHOULD NOT be<br> transmitted in the RTP payload unless reliable transport is provided<br> for RTP, as a loss of a parameter set of either type will likely<br> prevent decoding of a considerable portion of the corresponding RTP<br>
stream. Thus, the transmission of parameter sets using a reliable<br> session control protocol (i.e., usage of principle A or B above) is<br> RECOMMENDED.<br></pre>Botton line: correctly populate sprop-parameter-sets; you are wasting your time by not doing this.<br>