On Thu, Sep 24, 2009 at 12:46 AM, Stas Desyatnlkov <span dir="ltr">&lt;<a href="mailto:stas@tech-mer.com">stas@tech-mer.com</a>&gt;</span> wrote:<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;">









<div link="blue" vlink="purple" lang="EN-US">

<div>

<p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);">Hi,</span></p>

<p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);">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?</span></p>

<p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);">What if the h264 stream is packed inside TS and receiver is not
aware of anything else?</span></p>

<p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);">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?</span></p><br></div></div></blockquote><div><br>It depends.  If you&#39;re doing multicast, then sending it in-stream is a bad idea; clients may miss the first sending, which means you&#39;d have to do something weird like insert it when a client connects, or periodically insert it.  If you&#39;re doing unicast, it would probably work to send it once in-stream.  In my experience, some clients expect correct sprop-parameter-set and profile-level-id fields (e.g. quicktime), so not populating them is possibly a deal-breaker.<br>
<br>In any event, if you&#39;re on a LAN, why would you _ever_ consider not using the associated RTSP session to communicate this information?  And what sort of scenario do you have where there is &quot;no other means of communication besides RTP?&quot;  Quite frankly, I can&#39;t possibly think of a situation where either of these statements would be true.<br>
</div></div>