[Live-devel] Is there a mechanism for telling a client to switch streams?

[Ben Rush]

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.Morrill at 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 at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20160707/5b6595d9/attachment.html>