<div dir="ltr"><div><div>Why not add a metadata subsession  then you can put whatever you like in, for example, an XML payload.<br></div>In security cameras they put motion data, analytics, dewarp parameters, multicamera calibration etc.<br><br></div>Small amounts of information have also been put into the SEI But it sounds like you want to put new stream URIs etc.<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 7, 2016 at 4:32 AM, Ralf Globisch <span dir="ltr"><<a href="mailto:rglobisch@csir.co.za" target="_blank">rglobisch@csir.co.za</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Ben,<br>
<br>
> That's why I was curious if there was a standard mechanism for telling<br>
an rtsp client to switch to a<br>
different stream (in the case where the server is dictating the<br>
"adaptive" nature).<br>
<br>
There's no standard mechanism for that as far as I know.<br>
It is possible to implement what you want using live555 with a bit of<br>
effort.<br>
In the system we developed we have live encoded video at multiple<br>
qualities/rates and incoming RTCP reports determine which quality is<br>
streamed to each client.<br>
<br>
There may be other ways of doing this, but for us the trick was to have<br>
a DeviceSource per client<br>
(you need to set the reuseFirstSource to false in the<br>
OnDemandServerMediaSubsession).<br>
If you then have some shared buffers that stored the video of multiple<br>
qualities,<br>
each device source can store which buffer it is currently pulling video<br>
from.<br>
The more challenging part for me was to integrate a mechanism to respond<br>
to the RTCP reports.<br>
<br>
> ...and back to the latency concern: since these are nurses watching<br>
webcam<br>
feeds, even if there is a slight blip when jumping streams, we would<br>
prefer<br>
that to a stream being behind by a couple seconds (at most). Our prefer<br>
is<br>
sub-second latency. So the transition being "smooth" isn't probably as<br>
crucial as I had lead you to believe.<br>
<br>
Sub-second is really hard, but in my experience this is more of a<br>
client/play-out/player challenge.<br>
There is no delay on the server side as you can stream each incoming<br>
frame immediately.<br>
You do need to consider how you intend to switch from one stream to<br>
another:<br>
- You'll need to wait for the next IDR in the target quality stream<br>
(unless you don't mind artifacts), so how often are you going<br>
to have IDRs in the stream<br>
- keep in mind that IDR frames are much bigger than P-frames and<br>
frequent insertion of IDRs will likely have an impact on the rate of the<br>
stream<br>
- Switching to a lower quality you may/will still get a short spike in<br>
rate which may or may not be a problem.<br>
In any case, if you switched to another RTSP stream, you would incur<br>
this overhead anyway...<br>
<br>
Hope that helps,<br>
Ralf<br>
<br>
On Wed, Jul 6, 2016, 6:39 PM Jeremiah Morrill<br>
<<a href="mailto:Jeremiah.Morrill@econnect.tv">Jeremiah.Morrill@econnect.tv</a>><br>
wrote:<br>
<br>
> AFAIK, there’s no built in mechanism for adaptive streaming.<br>
><br>
><br>
><br>
> There are some things you can do, but may not be flexible enough.  For<br>
> instance, if you have a low-res-h264 and high-res-h264 version of a<br>
video,<br>
> in the server code, you could switch which file you are reading from,<br>
seek<br>
> to the same point in the media and start outputting those samples.<br>
You<br>
> will need to make sure you send out the SPS and PPS NALs that belong<br>
to the<br>
> new stream first though.  Things get a little more<br>
complicated/impossible<br>
> with codecs that don’t support this, and of course audio.<br>
><br>
><br>
><br>
> Again, AFAIK, your best bet may be a higher level application strategy<br>
of<br>
> detecting packet loss and immediately dropping to a lower bitrate url<br>
in<br>
> the background until enough of your client play-through buffer is<br>
ready.<br>
> This won’t be seamless, but I don’t think real-time protocols and<br>
adaptive<br>
> streaming mesh well.  You may be better off using something that is<br>
made<br>
> for this, like HLS, DASH or smooth-streaming.  Those methods of<br>
streaming<br>
> are tuned to download chunks of media (ex 2seconds worth), and if it<br>
cannot<br>
> download them faster than real-time, it will start downloading the<br>
smaller<br>
> bitrate chunks of media.  The way the chunks are written are specially<br>
> designed to be seamless (specially in the context of audio).<br>
><br>
><br>
><br>
> -Jer<br>
> _______________________________________________<br>
> live-devel mailing list<br>
> <a href="mailto:live-devel@lists.live555.com">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>
><br>
<br>
--<br>
This message is subject to the CSIR's copyright terms and conditions,<br>
e-mail legal notice, and implemented Open Document Format (ODF)<br>
standard.<br>
The full disclaimer details can be found at<br>
<a href="http://www.csir.co.za/disclaimer.html" rel="noreferrer" target="_blank">http://www.csir.co.za/disclaimer.html</a>.<br>
<br>
This message has been scanned for viruses and dangerous content by<br>
Mail<br>
<br>
--<br>
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.<br>
The full disclaimer details can be found at <a href="http://www.csir.co.za/disclaimer.html" rel="noreferrer" target="_blank">http://www.csir.co.za/disclaimer.html</a>.<br>
<br>
This message has been scanned for viruses and dangerous content by MailScanner,<br>
and is believed to be clean.<br>
<br>
Please consider the environment before printing this email.<br>
<br>
_______________________________________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com">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><br></div></div></div>