Hi, thanks for your great response. 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.
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. 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). ...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. On Wed, Jul 6, 2016, 6:39 PM Jeremiah Morrill <jeremiah.morr...@econnect.tv> wrote: > AFAIK, there’s no built in mechanism for adaptive streaming. > > > > 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. > > > > 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). > > > > -Jer > _______________________________________________ > live-devel mailing list > live-devel@lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel >
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
