<p dir="ltr">Hi, thanks for your great response. </p>
<p dir="ltr">There's actually a few reasons why we prefer using rtsp if possible. One of which is the time-sensitive nature of the content: we are in hospitals and delivering real time streams of patients. Being even a few seconds off could mean a patient falling. I have seen mention of MPEG dash achieving very low latency, but ultimately I believe rtsp will probably outperform dash in many instances. Being real time is absolutely crucial. </p>
<p dir="ltr">Second is that we already have a fairly substantial investment in rtsp through live555, what is in the field works well, and I have a growing amount of domain expertise in the libraries. </p>
<p dir="ltr">Third is that I may have tripped you up a bit, perhaps, by using the term adaptive. In our particular use case we are fine providing a number of available streams and simply telling the client to hop from one to the other. It doesn't have to be the same stream. That's why I was curious if there was a standard mechanism for telling an rtsp client to switch to a different stream (in the case where the server is dictating the "adaptive" nature). </p>
<p dir="ltr">...and back to the latency concern: since these are nurses watching webcam feeds, even if there is a slight blip when jumping streams, we would prefer that to a stream being behind by a couple seconds (at most). Our prefer is sub-second latency. So the transition being "smooth" isn't probably as crucial as I had lead you to believe. </p>
<br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 6, 2016, 6:39 PM Jeremiah Morrill <<a href="mailto:Jeremiah.Morrill@econnect.tv">Jeremiah.Morrill@econnect.tv</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="#954F72">
<div>
<p class="MsoNormal">AFAIK, there’s no built in mechanism for adaptive streaming.
</p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">There are some things you can do, but may not be flexible enough. For instance, if you have a low-res-h264 and high-res-h264 version of a video, in the server code, you could switch which file you are reading from, seek to the same point
in the media and start outputting those samples. You will need to make sure you send out the SPS and PPS NALs that belong to the new stream first though. Things get a little more complicated/impossible with codecs that don’t support this, and of course audio.</p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Again, AFAIK, your best bet may be a higher level application strategy of detecting packet loss and immediately dropping to a lower bitrate url in the background until enough of your client play-through buffer is ready. This won’t be seamless,
but I don’t think real-time protocols and adaptive streaming mesh well. You may be better off using something that is made for this, like HLS, DASH or smooth-streaming. Those methods of streaming are tuned to download chunks of media (ex 2seconds worth),
and if it cannot download them faster than real-time, it will start downloading the smaller bitrate chunks of media. The way the chunks are written are specially designed to be seamless (specially in the context of audio).</p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">-Jer<u></u><u></u></p>
</div>
</div>
_______________________________________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com" target="_blank">live-devel@lists.live555.com</a><br>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" rel="noreferrer" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
</blockquote></div>