[Live-devel] H264 multicast streaming question

Stas Desyatnlkov stas at tech-mer.com
Thu Sep 24 00:46:37 PDT 2009


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-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of spopo316 at 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 <kidjan at gmail.com> 寫道:

寄件者: Jeremy Noring <kidjan at gmail.com>
主旨: Re: [Live-devel] H264 multicast streaming question
收件者: "LIVE555 Streaming Media - development & use" <live-devel at ns.live555.com>
日期: 2009年9月11日,五,上午7:14
2009/9/10 <spopo316 at yahoo.com.tw<http://tw.mc723.mail.yahoo.com/mc/compose?to=spopo316@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 at lists.live555.com<http://tw.mc723.mail.yahoo.com/mc/compose?to=live-devel@lists.live555.com>
http://lists.live555.com/mailman/listinfo/live-devel


___________________________________________________
您的生活即時通 - 溝通、娛樂、生活、工作一次搞定!
http://messenger.yahoo.com.tw/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20090924/dad5b3b1/attachment-0001.html>


More information about the live-devel mailing list