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

[Ralf Globisch]

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.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
>

-- 
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.