Hi, Its obvious that loss of the SPS or PPS results in a lot of grief in the h264 land. The question is what choice do we have in case of no other means of communication besides RTP? What if the h264 stream is packed inside TS and receiver is not aware of anything else? I guess in case of LAN streaming where packet loss is rare sending SPS/PPS inband is not that bad of an option would you agree?
From: live-devel-boun...@ns.live555.com [mailto:live-devel-boun...@ns.live555.com] On Behalf Of spopo...@yahoo.com.tw Sent: Thursday, September 24, 2009 4:32 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] H264 multicast streaming question Hi Jeremy: Thanks for your advice. When i set correct SPS/PPS,then i can streaming H264 file now. Thanks Best Regards --- 09/9/11 (五)，Jeremy Noring <kid...@gmail.com> 寫道： 寄件者: Jeremy Noring <kid...@gmail.com> 主旨: Re: [Live-devel] H264 multicast streaming question 收件者: "LIVE555 Streaming Media - development & use" <live-de...@ns.live555.com> 日期: 2009年9月11日,五,上午7:14 2009/9/10 <spopo...@yahoo.com.tw<http://tw.mc723.mail.yahoo.com/mc/compose?to=spopo...@yahoo.com.tw>> 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? 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: The picture and sequence parameter set NALUs SHOULD NOT be transmitted in the RTP payload unless reliable transport is provided for RTP, as a loss of a parameter set of either type will likely prevent decoding of a considerable portion of the corresponding RTP stream. Thus, the transmission of parameter sets using a reliable session control protocol (i.e., usage of principle A or B above) is RECOMMENDED. Botton line: correctly populate sprop-parameter-sets; you are wasting your time by not doing this. -----內含下列夾帶檔案----- _______________________________________________ live-devel mailing list live-devel@lists.live555.com<http://tw.mc723.mail.yahoo.com/mc/compose?to=live-de...@lists.live555.com> http://lists.live555.com/mailman/listinfo/live-devel ___________________________________________________ 您的生活即時通 － 溝通、娛樂、生活、工作一次搞定！ http://messenger.yahoo.com.tw/
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
