Hi Ben, > 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).
There's no standard mechanism for that as far as I know. It is possible to implement what you want using live555 with a bit of effort. In the system we developed we have live encoded video at multiple qualities/rates and incoming RTCP reports determine which quality is streamed to each client. There may be other ways of doing this, but for us the trick was to have a DeviceSource per client (you need to set the reuseFirstSource to false in the OnDemandServerMediaSubsession). If you then have some shared buffers that stored the video of multiple qualities, each device source can store which buffer it is currently pulling video from. The more challenging part for me was to integrate a mechanism to respond to the RTCP reports. > ...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. Sub-second is really hard, but in my experience this is more of a client/play-out/player challenge. There is no delay on the server side as you can stream each incoming frame immediately. You do need to consider how you intend to switch from one stream to another: - You'll need to wait for the next IDR in the target quality stream (unless you don't mind artifacts), so how often are you going to have IDRs in the stream - keep in mind that IDR frames are much bigger than P-frames and frequent insertion of IDRs will likely have an impact on the rate of the stream - Switching to a lower quality you may/will still get a short spike in rate which may or may not be a problem. In any case, if you switched to another RTSP stream, you would incur this overhead anyway... Hope that helps, Ralf 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 > -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by Mail -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
